/
Автор: Шривастава С. Шривастав Н.
Теги: система управления базами данных (субд) архитектура вычислительных машин информационные машины машины для обработки данных вычислительные машины и устройства дискретного действия (цифровые вычислительные машины и устройства) базы данных информационные технологии вычислительная техника компьютерные технологии
ISBN: 978-601-12-3976-9
Год: 2026
Текст
EXPERT INSIGHT
SP?iNT
book
Solutions
architect
Архитектура и проектирование ИТ-решений
Третье издание
Саурабх Шривастава
Ниланджали Шривастав
<packt>
Solutions Architect's Handbook
Third Edition
Kick-start your career with architecture design principles,
strategies, and generative Al techniques
Saurabh Shrivastava
Neelanjali Srivastav
<packt>
Solutions architect
Третье издание
Архитектура и проектирование
ИТ-решений
Саурабх Шривастава
Ниланджали Шривастав
>?iNT
Book 2026
Саурабх Шривастава, Ниланджали Шривастав
Solutions architect: Архитектура
и проектирование ИТ-решений, 3-е изд.
Перевел с английского Е. Матвеев
ББК 32.973.233.02+32.972.2-01
УДК 004.65+004.2
Шривастава Саурабх, Шривастав Ниланджали
Ш86 Solutions architect: Архитектура и проектирование ИТ-решений, 3-е изд. — Астана:
«Спринт Бук», 2025. — 640 с.: ил. — (Серия «Библиотека программиста»).
ISBN 978-601-12-3976-9
Овладейте искусством дизайна архитектур и станьте успешным архитектором решений. Книга, на-
писанная опытными техлидами AWS Саурабхом Шриваставой и Ниланджали Шривастав, выходит за
рамки традиционных руководств для подготовки к сертификации. В ней вы найдете подробную аналитику
и описания передовых методов, предназначенных для удовлетворения конкретных потребностей клиентов
и решения проблем, с которыми сталкиваются современные архитекторы решений.
Издание описывает новые интересные возможности, которые позволят вам оставаться в авангарде этой
стремительно развивающейся сферы. Большие языковые модели, генеративный ИИ, инновации в области
глубокого обучения — все эти революционные достижения формируют будущее технологии. Такие темы,
как облачно-ориентированные архитектуры, инженерия данных, облачная оптимизация, модернизация
мейнфреймов и создание экономичных и безопасных архитектур, продолжают оставаться актуальными
в современной технологической сфере. В книге рассматриваются эти перспективные и ключевые техно-
логии, а также приводится пошаговое описание процесса проектирования архитектур решений, начиная
с ключевых принципов. Она снабдит вас знаниями, необходимыми, чтобы стать успешным архитектором
решений. Кроме того, книга поможет усовершенствовать гибкие навыки и тем самым получить возмож-
ность для развития карьеры.
Раскройте потенциал передовых технологий, изучайте практические выводы на реальных сценариях
и повышайте мастерство.
16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)
ISBN 978-601-12-3976-9
© Packt Publishing 2024.
First published in the English language under the title ‘Solutions
Architect’s Handbook - Third Edition - (9781835084236)’
© Перевод на русский язык ТОО «Спринт Бук», 2025
© Издание на русском языке, оформление ТОО «Спринт Бук», 2025
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без
письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные.
Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать
абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные
с использованием книги.
Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге.
На момент подготовки книги к изданию все ссылки на интернет-ресурсы были действующими.
Изготовлено в России. Изготовитель: ТОО «Спринт Бук». Место нахождения и фактический адрес:
010000, Казахстан, город Астана, район Алматы, проспект Ракымжан Кошкарбаев, дом 10/1, и. и. 18.
Дата изготовления: 11.2025. Наименование: книжная продукция. Срок годности: не ограничен.
Подписано в печать 26.09.25. Формат 70x100/16. Бумага офсетная. Усл. и. л. 51,600. Тираж 700. Заказ 0000.
ОГЛАВЛЕНИЕ
От издательства.................................................17
Предисловие.....................................................18
Создатели книги.................................................22
Введение........................................................25
Глава 1. Архитекторы решений в организациях.....................29
Что такое архитектура решения?................................30
Преимущество архитектуры решения...........................30
Роль архитектора решений......................................33
Роли архитекторов широкого профиля.........................35
Роли архитекторов специализированных решений...............39
Обязанности архитектора решений...............................49
Анализ функциональных требований (ФТ)......................50
Определение НФТ............................................51
Понимание и вовлечение стейкхолдеров.......................53
Архитектурные ограничения..................................54
Выбор технологии...........................................56
Проверка концепции и прототип..............................57
Проектирование и поставка решения..........................57
Масштабирование решений и технологический евангелизм.......59
Архитектор решений в Agile-организациях.......................59
Типичные сложности в работе архитектора решений...............60
Карьерный путь и развитие навыков архитектора решений.........62
Карьерный путь.............................................62
Развитие навыков...........................................62
Итоги.........................................................64
Глава 2. Принципы проектирования архитектур решений.............66
Построение масштабируемых архитектур..........................67
Масштабирование статического контента......................70
Построение устойчивой архитектуры с высокой доступностью......75
Архитектура с высокой доступностью.........................75
6 Оглавление
Устойчивая архитектура......................................75
Достижение избыточности.....................................76
Обработка отказов компонентов...............................77
Отказоустойчивые архитектуры..................................78
Проектирование с учетом производительности....................80
Создание неизменяемой архитектуры.............................81
Слабая связанность............................................83
Сервисы, а не серверы.........................................85
Проектирование на основе данных...............................86
Забота о безопасности на всех уровнях.........................87
Удобство использования и доступность приложений...............89
Удобство использования......................................89
Доступность.................................................90
Построение расширяемой и future-proof архитектуры,
подходящей для повторного использования ......................91
Архитектурная интероперабельность и портируемость.............93
Интероперабельность приложений..............................93
Портируемость приложений....................................94
Повсеместное применение автоматизации.........................94
Планирование непрерывности бизнеса............................96
Проектирование с учетом эксплуатации........................98
Преодоление архитектурных ограничений.........................99
Метод MVP..................................................100
Итоги........................................................101
Глава 3. Миграция на облачные платформы и проектирование
облачных архитектур.............................................103
Публичные, частные и гибридные облачные платформы............104
Архитектура решения в публичном облаке.......................105
Публичная облачная архитектура.............................106
Популярные провайдеры публичных облачных платформ..........108
Облачно-ориентированная архитектура........................108
Проектирование облачно-ориентированных архитектур..........110
Стратегии облачной миграции..................................112
Миграция lift-and-shift ...................................115
Облачно-ориентированный подход.............................117
Сохранение или вывод из эксплуатации.......................119
Выбор стратегии облачной миграции............................121
Этапы облачной миграции......................................123
Инвентаризация.............................................125
Анализ информации..........................................127
Оглавление 7
Составление плана миграции................................128
Проектирование приложения.................................130
Выполнение миграции приложения в облако...................134
Интеграция, проверка и переключение.......................138
Эксплуатация облачного приложения.........................141
Оптимизация приложений в облаке...........................142
Создание гибридной облачной архитектуры......................143
Мультиоблачные решения.......................................146
Реализация CloudOps..........................................147
Принципы CloudOps.........................................148
Итоги........................................................150
Дополнительные источники.....................................151
Глава 4. Паттерны проектирования архитектур решений............152
Построение ^-уровневой архитектуры........................153
Веб-уровень...............................................154
Уровень приложения........................................154
Уровень базы данных.......................................155
Создание мультитенантной архитектуры на базе SaaS............156
Сервис-ориентированная архитектура...........................158
RESTful-архитектура.......................................159
Создание сайта интернет-магазина на базе RESTful-архитектуры.161
Построение архитектуры на базе кэша.......................163
Паттерн Cashe distribution (Распределенное кэширование)
в трехуровневой веб-архитектуре...........................166
Паттерн Rename distribution (Распределение с переименованием).167
Паттерн Cache proxy (Кэширующий прокси-сервер)............168
Паттерн Rewrite proxy (Заменяющий прокси-сервер)..........169
Паттерн Арр caching (Кэширование на уровне приложения)....171
Memcached и Redis.........................................172
Архитектура MVC (Model-View-Controller)......................173
Применение MV С при проектировании книжного
интернет-магазина.........................................175
Предметно-ориентированное проектирование..................176
Паттерн Circuit Breaker («Предохранитель»)...................178
Реализация паттерна Bulkhead («Переборка»)...................179
Создание паттерна Floating IP (Плавающий IP)..............180
Развертывание приложения в контейнере........................182
Преимущества контейнеров..................................183
Контейнерное развертывание................................184
Построение архитектуры на базе контейнеров................186
8
Оглавление
Работа с базой данных в архитектуре приложения..............188
Паттерн High-availability Database (База данных с высокой
доступностью)...............................................189
Паттерн Clean Architecture (Чистая архитектура).............191
Как избежать антипаттернов в архитектуре решений............192
Итоги.........................................................194
Глава 5. Паттерны проектирования облачно-ориентированных
архитектур.......................................................196
Что такое облачно-ориентированная архитектура.................197
Бессерверная архитектура......................................200
Факторы проектирования бессерверных архитектур..............202
Дизайн архитектуры с сохранением и без сохранения состояния...204
Архитектура с сохранением состояния.........................205
Архитектура без сохранения состояния........................206
Микросервисная архитектура....................................208
Паттерн Saga (Сага).........................................212
Паттерн Fan-out/Fan-in (Разветвление/схождение).............215
Паттерн Service mesh (Сервисная сетка) .....................217
Реактивная архитектура........................................222
Архитектура на базе очереди...................................225
Паттерн Queuing Chain (Цепочка очередей)....................226
Паттерн Job Observer (Наблюдатель заданий)..................228
Архитектура Pipes-and-Filters (Каналы и фильтры)..............229
Архитектура, управляемая событиями............................230
Модель Publisher/subscriber (Издатель/подписчик)............231
Модель Event stream (Поток событий).........................232
Паттерн BFF (Backend for Frontend)............................234
Облачно-ориентированные архитектурные антипаттерны............235
Единая точка сбоя...........................................235
Ручное масштабирование......................................236
Сильносвязанные сервисы.....................................236
Игнорирование лучших практик безопасности...................236
Отсутствие мониторинга или ведения журналов.................236
Игнорирование сетевой задержки..............................237
Недостаточное тестирование..................................237
Чрезмерная оптимизация......................................237
Игнорирование затрат........................................237
Итоги.........................................................238
Оглавление 9
Глава 6. Факторы производительности............................240
Принципы проектирования высокопроизводительных архитектур...240
Сокращение задержки.......................................241
Повышение пропускной способности..........................242
Конкурентность............................................245
Кэширование...............................................246
Выбор технологии для оптимизации производительности.........247
Выбор вычислительного ресурса.............................248
Выбор типа хранилища......................................255
Выбор базы данных.........................................261
Повышение производительности сети.........................265
Факторы производительности для мобильных приложений.........271
Оптимизация времени загрузки..............................271
Эффективное использование ресурсов........................271
Отзывчивость пользовательского интерфейса (UI)............271
Эффективность сети........................................272
Расход заряда батареи.....................................272
Кросс-платформенная совместимость.........................272
UX-дизайн.................................................272
Эффективное управление данными............................272
Тестирование и контроль качества..........................272
Тестирование производительности.............................273
Виды тестирования производительности......................273
Мониторинг производительности...............................275
Итоги.......................................................276
Глава 7. Факторы безопасности..................................278
Принципы проектирования безопасной архитектуры..............279
Аутентификация и авторизация..............................279
Повсеместное применение безопасности......................280
Сокращение радиуса поражения..............................280
Постоянный мониторинг и аудит.............................281
Повсеместная автоматизация................................281
Защита данных.............................................282
Ответ на инциденты безопасности...........................283
Выбор технологий для безопасности архитектуры...............283
Идентификационные данные пользователей
и управление доступом.....................................284
10 Оглавление
Веб-безопасность.........................................294
Защита приложения и его инфраструктуры...................300
Безопасность данных......................................307
Защита API...............................................311
Сертификация безопасности и соответствия....................314
Модель общей ответственности за безопасность в облаке.......315
Моделирование угроз.........................................318
Итоги.......................................................320
Глава 8. Факторы надежности архитектуры.......................321
Принципы проектирования для надежности архитектуры..........322
Самовосстановление систем за счет применения автоматизации.322
Создание распределенной системы..........................324
Мониторинг и добавление емкости..........................324
Проверка восстановления при сбоях........................325
Выбор технологии для архитектурной надежности...............326
Планирование RPO и RTO...................................326
Репликация данных........................................327
Планирование DR..........................................330
Применение лучших DR-практик.............................341
Повышение надежности в облаке...............................342
Итоги.......................................................343
Глава 9. Операционное совершенство............................345
Принципы проектирования для операционного совершенства......346
Автоматизация ручных задач...............................346
Инкрементные и обратимые изменения.......................347
Прогнозирование сбоев и реагирование.....................347
Анализ ошибок и выводы...................................348
Актуализация ранбука.....................................348
Выбор технологий для операционного совершенства.............349
Планирование операционного совершенства..................349
Управление ИТ-активами...................................350
Достижение операционного совершенства....................355
Развитие операционного совершенства......................365
Достижение операционного совершенства на публичных
облачных платформах.........................................369
Повышение эффективности с CloudOps.........................370
Итоги.......................................................372
Глава 10. Оптимизация затрат..................................373
Принципы проектирования для оптимизации затрат..............374
Вычисление суммарной стоимости владения..................374
Оглавление 11
Планирование бюджета и прогнозирование...................376
Потребности и каталоги сервисов..........................378
Отслеживание расходов....................................379
Непрерывная оптимизация затрат...........................380
Приемы оптимизации затрат..................................382
Сокращение архитектурной сложности.......................382
Повышение эффективности ИТ...............................384
Применение стандартизации и управления...................386
Тегирование затрат ресурсов..............................388
Мониторинг затрат и отчеты...............................390
Оптимизация затрат на публичных облачных платформах........394
Зеленые ИТ и их влияние на затраты.........................396
Размещение экономичных и зеленых приложений в AWS........397
Итоги......................................................400
Глава 11. DevOps и фреймворк архитектуры решений..............402
Знакомство с DevOps........................................403
Преимущества DevOps......................................404
Составляющие DevOps........................................406
Непрерывная интеграция / непрерывное развертывание.......406
Непрерывный мониторинг и улучшения.......................408
Инфраструктура как код...................................409
У правление конфигурацией................................412
DevSecOps..................................................414
Объединение DevSecOps и CI/CD..............................415
Реализация стратегии CD....................................417
Развертывание на месте...................................418
Скользящее развертывание.................................418
Сине-зеленое развертывание...............................418
Красно-черное развертывание..............................420
Неизменяемое развертывание...............................421
Выбор стратегии развертывания: лучшие практики.............421
Реализация непрерывного тестирования в пайплайне CI/CD.....423
А/В-тестирование.........................................425
Инструменты DevOps для CI/CD...............................427
Редактор кода............................................427
Управление исходным кодом................................427
Сервер CI................................................428
Развертывание кода.......................................430
Пайплайн кода............................................432
Реализация лучших практик DevOps...........................433
Создание процессов DevOps и DevSecOps на облачных платформах.435
Итоги......................................................438
12 Оглавление
Глава 12. Инженерия данных для архитектур решений.............439
Что представляет собой архитектура Big Data?................440
Проектирование пайплайнов обработки Big Data................442
Поглощение данных, сохранение, обработка и аналитика........444
Поглощение данных........................................445
Выбор технологии поглощения данных.......................446
Поглощение данных в облаке...............................447
Хранение данных..........................................449
Выбор технологии хранения данных.........................451
Хранение структурированных данных........................451
Реляционные базы данных..................................452
Хранилища данных (data warehouses).......................452
Базы данных NoSQL........................................454
Сравнение баз данных SQL и NoSQL.........................454
Виды баз данных NoSQL....................................456
Поисковые хранилища данных...............................456
Хранилища неструктурированных данных.....................457
Объектное хранилище......................................457
Векторные базы данных (VectorDB).........................458
Хранилище блокчейн-данных................................459
Хранилища потоковых данных...............................461
Хранение данных в облаке....................................462
Обработка данных и аналитика.............................464
Выбор технологии для обработки и анализа данных..........466
Обработка данных в облаке................................468
Визуализация данных.........................................470
Технологии визуализации данных...........................470
Проектирование архитектур Big Data..........................471
Архитектура озера данных (data lake).....................474
Архитектура озера-хранилища данных (data lakehouse)......477
Архитектура сетки данных (data mesh).....................479
Архитектура потоковых данных.............................481
Выбор подходящей архитектуры Big Data....................483
Лучшие практики архитектуры Big Data........................485
Итоги.......................................................487
Глава 13. Архитектура машинного обучения......................489
Что такое машинное обучение?................................490
Типы машинного обучения..................................492
Data science и машинное обучение............................495
Оценка моделей МО — переобучение и недостаточное обучение.498
Оглавление 13
Популярные алгоритмы машинного обучения..................499
Популярные инструменты и фреймворки машинного обучения....502
Машинное обучение в облаке.................................508
Построение архитектуры машинного обучения..................509
Подготовка и разметка....................................510
Выбор и построение модели................................511
Обучение и настройка модели..............................511
Развертывание модели и управление ею.....................512
Референсная архитектура МО...............................513
Принципы проектирования архитектуры машинного обучения.....515
Модульность..............................................516
Масштабируемость.........................................516
Воспроизводимость........................................516
Контроль качества данных.................................517
Гибкость.................................................517
Робастность и надежность.................................518
Конфиденциальность и безопасность........................518
Эффективность............................................518
Интерпретируемость.......................................519
Способность работы в режиме реального времени............519
Отказоустойчивость.......................................520
MLOps......................................................521
Принципы MLOps...........................................521
Лучшие практики MLOps....................................523
Глубокое обучение..........................................525
Глубокое обучение в реальных условиях....................528
NLP........................................................529
Чат-боты и виртуальные помощники.........................529
Анализ тональности текста ...............................529
Реферирование текста .....................................530
Машинный перевод.........................................530
Итоги......................................................530
Глава 14. Архитектура генеративного ИИ........................532
Что такое генеративный ИИ?.................................533
Сценарии использования генеративного ИИ....................534
Преобразование взаимодействий с пользователями...........535
Повышение производительности труда.......................535
Оптимизация бизнес-операций..............................536
Базовая архитектура систем генеративного ИИ................537
Типы генеративных моделей................................538
14 Оглавление
Генеративно-состязательные сети (GAN).....................538
Вариационные автоэнкодеры (VAE) ..........................541
Генеративные модели на базе трансформеров.................542
Другие важные генеративные модели.........................545
Важность настройки гиперпараметров и регуляризации........545
Фундаментальные модели генеративного ИИ.....................547
Как начать работу с генеративным ИИ.......................550
Использование ФМ генеративного ИИ в приложениях
публичных облачных провайдеров............................554
Выбор подходящей ФМ.......................................558
Предотвращение галлюцинаций модели........................559
Референсная архитектура генеративного ИИ на примере ассистента
по ипотечному кредитованию..................................562
Проблемы реализации генеративного ИИ........................564
Проблема стабильности обучения............................564
Схлопывание мод распределения ............................565
Проблемы с интерполяцией скрытого пространства............565
Этические соображения и злоупотребления...................566
Итоги.......................................................567
Глава 15. Переработка архитектуры унаследованных систем........568
Проблемы унаследованных систем..............................569
Отставание от потребностей пользователей..................570
Высокие затраты на обслуживание и обновление..............571
Нехватка квалификации и документации......................571
Уязвимости в системе корпоративной безопасности...........572
Несовместимость с другими системами.......................573
Определение стратегии модернизации..........................574
Оценка унаследованного приложения.........................575
Определение метода модернизации...........................576
Преимущества модернизации систем..........................578
Методы модернизации унаследованных систем...................580
Инкапсуляция, рехостинг и смена платформы.................581
Рефакторинг и переработка архитектуры.....................581
Перепроектирование и замена...............................582
Определение стратегии облачной миграции для унаследованных
систем......................................................583
Документация и поддержка..................................586
Миграция мейнфреймов на публичные облачные платформы........586
Проблемы модернизации мейнфреймов.........................587
Оглавление 15
Миграция автономных приложений............................588
Миграция приложений с совместно используемым кодом........589
Преимущества использования публичной облачной платформы
для модернизации мейнфреймов.............................593
Модернизация унаследованного кода с помощью GenAI...........595
Итоги.......................................................596
Глава 16. Документирование архитектуры решений................598
Назначение SAD..............................................599
Представления SAD...........................................600
Структура SAD...............................................602
Обзор решения............................................604
Бизнес-контекст..........................................607
Концептуальный обзор решения.............................609
Архитектура решения......................................610
Реализация решения.......................................616
Управление решением......................................616
Приложение...............................................617
Жизненный цикл SAD..........................................618
Лучшие практики и типичные ошибки SAD.......................618
Документация на закупку IT-ресурсов для архитектуры решения.619
Итоги.......................................................622
Глава 17. Гибкие навыки, которые нужны хорошему архитектору
решений.......................................................623
Важность гибких навыков ....................................624
Приобретение навыков предварительных продаж.................625
Ключевые навыки..........................................625
Представление решения руководителям высшего звена........626
Принятие владения и ответственности за результат............628
Определение исполнения стратегии с учетом OKR............628
Масштабное мышление......................................630
Гибкость и адаптируемость...................................631
Дизайн-мышление.............................................632
Участие в написании кода....................................635
Развитие благодаря непрерывному обучению....................635
Роль ментора................................................638
Роль технологического евангелиста и лидера мнений...........638
Итоги.......................................................639
Нашим любимым детям Санви и Шубху;
они — бесконечные радость и счастье,
озаряющие наши жизни.
Саурабх и Ниланджали
ОТ ИЗДАТЕЛЬСТВА
Мы выражаем огромную благодарность клубу рецензентов ИТ-литературы
ReadIT Club за помощь в работе над русскоязычным изданием книги и вклад
в повышение качества переводной литературы.
Ваши замечания, предложения, вопросы отправляйте по адресу
comp@sprintbook.kz (издательство «SprintBook», компьютерная редакция).
Мы будем рады узнать ваше мнение!
О научном редакторе русского издания
Владимир Бурмистров — архитектор платформенных решений в компании Т1.
Опыт в ИТ и разработке более 18 лет. Занимается проектированием высоко-
нагруженных решений, преподает системный анализ и программирование.
Постоянный спикер на конференциях по различным темам: от управления
командой до контроля качества кода.
ПРЕДИСЛОВИЕ
Роль архитектора решений (solutions architect) требует уникального набора
навыков, охватывающих всю широту и глубину технологий, а также умения увя-
зывать технические решения с интересами бизнеса и извлекать из них прибыль.
Распространение облачных платформ ускоряется, и в компаниях становятся
востребованы специалисты с навыками архитекторов решений, которые могут
упростить цифровую трансформацию компании с упором на облачные техноло-
гии. Облако предлагает совершенно иные преимущества и включает ряд готовых
инструментов и сервисов, заменяющих дорогостоящие сторонние лицензионные
программные продукты. Облачные платформы способны за считаные минуты
обеспечить требуемые надежность и масштабируемость, чтобы не упустить
периоды высокого роста и сезонных колебаний. Облачно-ориентированные
сервисы подходят для создания высокопроизводительных приложений при не-
больших затратах. За более чем 25 лет опыта работы в ИТ-отрасли, занимаясь
разработкой сложных и высокомасштабируемых приложений, я приобрел стой-
кое убеждение в том, что правильный выбор архитектуры позволяет клиентам
извлечь максимальную пользу из облачных стратегий.
Эта книга восполняет пробелы в знаниях и навыках. В ней лучшие архитектурные
практики представлены через призму облачных технологий. Книга начинается
с объяснения роли и обязанностей архитектора решений, а затем раскрывает
основные принципы проектирования архитектур. Хотя центральное место
в книге занимают облачные стратегии, в ней также рассматривается широкий
спектр тем, от миграции в облако до проектирования архитектур облачно-ори-
ентированных решений. В книге описано свыше 50 основных паттернов проек-
тирования архитектур при разработке приложений с конкретными примерами
для их наглядного представления. Архитекторы решений должны учитывать
все аспекты проектирования и глубоко разбираться в каждой из этих тем, чтобы
оптимизировать такие параметры архитектуры, как безопасность, надежность,
производительность, затраты и эффективность в эксплуатации.
Третье издание книги для меня особенно ценно, поскольку в нем подробно рас-
сматриваются паттерны облачно-ориентированной архитектуры, а также тема
генеративного искусственного интеллекта (GenAI). Архитектура генеративного
ИИ и фундаментальных моделей описана весьма основательно, с представ-
лением набора инструментов генеративного ИИ и потенциальных вариантов
их применения. Кроме того, в книге большое внимание уделено технологиям
Предисловие 19
хранения данных, которые играют исключительно важную роль при разработке
стабильных инфраструктур для расширенной аналитики и машинного обучения.
Также вы найдете в книге полезную информацию об архитектуре машинного
обучения, CloudOps и MLOps, и исчерпывающее руководство по преобразо-
ванию генеративного ИИ и облачных приложений от прототипа к рабочему
экземпляру. Это издание не только расширит ваши знания, но и снабдит вас
практической информацией о том, как эффективно реализовать продвинутые
современные технологии.
Я часто встречаю людей, которые хотят поднять свою квалификацию на новый
уровень или сменить свой карьерный путь, чтобы стать архитектором решений.
Саурабх вложил в эту книгу годы своего практического опыта, благодаря чему
с ней будет легко работать каждому, кто захочет прокачать свои навыки в теку-
щей специализации или заняться изучением будущих технологий. В облачную
эпоху эта книга даст ответы на все ключевые вопросы начинающего или практи-
кующего архитектора решений, который стремится оставаться на пике знаний.
Раджеш Шет (Rajesh Sheth), вице-президент
AWS Elastic Block Store и AWSBackup
Третье издание книги «Solutions architect: архитектура и проектирование ИТ-
решений» было опубликовано в критический момент, когда пандемия COVID-19
ускорила цифровую трансформацию и внедрение облачных технологий. Книга
как нельзя вовремя отвечает на острую потребность в архитекторах решений
для перехода на облачно-ориентированные архитектуры и микросервисы. Вы
найдете в ней важнейшие рекомендации по масштабированию, операционной
устойчивости, аварийному восстановлению и непрерывности бизнеса. Книга
предоставляет перспективную точку зрения на разработку распределенных при-
ложений и стремительное распространение облачно-ориентированных решений,
отражая сдвиг парадигмы в технологических архитектурах.
Издание, в котором рассматриваются настолько разнообразные темы, от облач-
ной миграции и модернизации до передовых направлений машинного обучения
и генеративного ИИ, станет бесценным ресурсом для многих архитекторов.
Книга мастерски связывает вопросы модернизации унаследованных (легаси)
систем, включая факторы использования мейнфреймов, с новейшими фун-
даментальными моделями и инструментами генеративного ИИ и отличается
глубоким рассмотрением тенденций, формирующих будущее архитектурного
проектирования.
«Solutions architect: архитектура и проектирование ИТ-решений» выделяется
целостностью подхода. В ней рассматривается широкий спектр важных тем —
от функциональных архитектур и интеграции до расширяемости, возможности
повторного использования, юзабилити, доступности, управления затратами
и безопасности. Широта рассматриваемых вопросов и практических советов
делает ее бесценным источником информации как для начинающих, так и для
20 Предисловие
опытных архитекторов, желающих сориентироваться в сложностях современ-
ных облачно-центричных сред. Книга Саурабха и Ниланджали, основанная на
их богатом опыте, укажет верное направление всем, кто хочет добиться успеха
в стремительно развивающейся сфере архитектур решений.
Рохан Кармаркар (Rohan Karmarkar),
директор по архитектуре решений, AWS
Технологии всегда быстро движутся вперед, и чтобы преуспеть в этой отрасли,
ИТ-профессионал должен постоянно приобретать новые навыки. За послед-
нее десятилетие эта тенденция стала доминирующей, а облачные вычисления
превратились в «новую нормальность». Анонсы, новая функциональность
и обновления сервисов от облачных провайдеров появляются почти ежедневно,
что заставляет каждого, кто работает в ИТ-сфере, делать упор на непрерывное
обучение. Кроме того, начали размываться границы между привычными задачами
разработчика, администратора баз данных, специалиста по безопасности, билд/
релиз-инженера и т. д., что привело к созданию новых ролей, в центре внимания
которых — общая картина и сквозная ответственность. Одной из таковых стала
роль архитектора решений; она начала развиваться на базе существующих ролей
в отрасли (например, архитектора приложений и ИТ-архитектора) и сейчас
активно завоевывает популярность. У этой роли существуют разновидности;
тем не менее самым частым ее воплощением остается весьма динамичная роль
архитектора облачных решений.
ИТ-специалисты нередко хотят сменить роль, но им не хватает руководства, как
добиться успеха на этом пути. Книга фокусируется именно на этом аспекте —
успешном переходе с существующей ИТ-роли на роль архитектора решений.
В ней последовательно объясняются шаги, которые необходимо пройти на этом
пути. Сначала дается простое и понятное объяснение того, что означает роль
архитектора решений и чем она отличается от других схожих профилей. Затем
рассматриваются технические навыки и знания, необходимые для успешной ра-
боты архитектором решений. Объясняются базовые принципы проектирования
архитектуры (такие как высокая доступность, надежность, производительность,
безопасность и оптимизация затрат), после чего следует углубление в каждый
из этих аспектов. Книга также охватывает ключевые концепции, связанные
с облачно-ориентированными архитектурами, DevOps, а также инженерией
данных и машинным обучением, которые являются краеугольным камнем любой
современной архитектуры. В последней редакции книги Саурабх и Ниланджали
также добавили весьма содержательные детали по облачно-ориентированным
архитектурам, генеративному ИИ, глубокому обучению, CloudOps, расширенной
аналитике и миграции в облако. Все эти области постепенно становятся ключевы-
ми для корпоративного ИТ-ландшафта, и архитекторам решений крайне важно
быть в курсе современных трендов, чтобы всегда оказываться на шаг впереди.
Предисловие 21
Вместе с Саурабхом я прошел путь от тимлида разработчиков до архитектора
решений. В то время нам очень хотелось иметь руководство, которое бы нам
помогло, но его не было. И чтобы восполнить этот пробел, Саурабх написал
чрезвычайно подробную книгу, основанную на личном опыте и полученных
знаниях, благодаря которым она получилась доступной для всех. Я настоятель-
но рекомендую прочесть ее и держать под рукой — вы найдете в ней ценную
информацию, которая поможет вам стать успешным архитектором решений
и откроет новый мир бесконечных возможностей!
Камаль Арора (Kamal Arora),
директор по архитектуре решений, A WS
https://www.amazon.eom/Kamal-Arora/e/B07HLTSNRJ/
СОЗДАТЕЛИ КНИГИ
Об авторах
Саурабх Шривастава — технологический лидер, автор, изобретатель и спикер
с более чем 20-летним опытом работы в ИТ-отрасли. В настоящее время он
занимает должность руководящего архитектора глобальных решений в AWS
(Amazon Web Services), помогая партнерам AWS и клиентам осуществить пере-
ход к облачной платформе. Саурабх возглавлял глобальные технологические
партнерства AWS, определял видение и рабочую модель своей команды, а также
внедрил ряд новых стратегических инициатив.
Кроме своей работы в AWS, Саурабх является автором популярной книги из-
дательства Packt «AWS for Solutions Architects, Second edition», ведет блоги
и пишет статьи, посвященные различным технологиям: big data, 1оТ, машинному
обучению, облачным вычислениям и др. Он является большим энтузиастом
инноваций и их влияния на общество и повседневную жизнь. Саурабх владеет
несколькими патентами в области автоматизации облачных платформ. Он
работал архитектором корпоративных решений, архитектором программного
обеспечения, а также руководил разработками в компаниях из списка Fortune 50,
стартапах и глобальных организациях, занимающихся разработками и кон-
сультированием. Благодаря огромному опыту и квалификации Саурабха его
книги являются ценным источником информации для всех, кто захочет больше
узнать об облачных вычислениях и их возможном применении.
Ниланджали Шривастав приобрела обширные знания благодаря богатому опыту
работы в качестве технологического лидера, продакт-менеджера и agile-тренера.
В настоящее время она является лидером портфеля технических проектов в Ауа
Healthcare. Ранее она работала старшим продакт-менеджером в AWS, где помо-
гала клиентам и партнерам AWS пользоваться сервисами баз данных, аналитики
и машинного обучения AWS.
Ниланджали также участвовала в написании популярной книги издательства
Packt «AWS for Solutions Architects» — ценного источника информации для
всех, кто захочет начать карьеру архитектора решений AWS. Опыт руководства
командами разработчиков, архитекторов решений и системных аналитиков
в работе по модернизации ИТ-систем и в разработке инновационных про-
граммных решений для крупных компаний позволяет Ниланджали успешно
О рецензентах 23
осуществлять анализ возможных трудностей и новых возможностей в тех-
нологической сфере.
Опыт Ниланджали в управлении корпоративными приложениями, agile-
обучении, управлении облачными сервисами и корпоративными слияниями
и поглощениями делает ее востребованным докладчиком и лидером мнений в от-
расли. Она посвятила свою жизнь тому, чтобы помогать другим людям учиться
и строить карьеру, и ее вклад в эту область весьма значителен.
О рецензентах
Уэйн Р. Винсент (Wayne R. Vincent) имеет 40-летний опыт в области инфор-
мационных технологий, при этом около 30 лет — в должности корпоративного
архитектора в предпродажном секторе. Он обладает степенями бакалавра
и магистра computer science в Университете Нью-Хейвена, где также занимает
должность советника университетской программы Executive Micro MBA.
Уэйн работал в стартапах в сфере издания профессиональных книг и виртуа-
лизации данных, а также в крупных корпорациях, включая Sun Microsystems,
Oracle, AWS и Google. Во время работы в этих компаниях Уэйн вел клиентов из
многих отраслей, включая финансовые услуги, издательское дело, производство,
розничную торговлю и страхование.
Найджел Харрис (Nigel Harris) — авторитетный технологический лидер. Более
25 лет он помогал компаниям добиваться бизнес-целей за счет проектирования
и развертывания безопасных ИТ-инфраструктур и управления ими. Найджел
работал во многих технологических областях, включая данные и аналитику,
безопасность, автоматизацию DevOps и микросервисы. Сейчас он взаимодей-
ствует с клиентами AWS, предоставляя рекомендации и оказывая техническую
поддержку в вопросах архитектур AWS.
В настоящее время Найджел является старшим менеджером в AWS, где руко-
водит организацией архитектуры решений, помогая компаниям из Северной
Америки. Ранее Найджел работал ведущим архитектором решений в Amazon,
где поддерживал руководителей и технических стейкхолдеров в вопросах пла-
нирования, миграции и управления облачными инфраструктурами. Найджел
имеет 10 сертификаций AWS и участвует в подготовке сертификаций AWS
Professional and Security Specialty. До прихода в Amazon Найджел работал в гло-
бальной технологической производственной организации из списка Fortune 500
на разных технических и менеджерских должностях.
Вирадж Падте (Viraj Padte) имеет более 8 лет опыта разработки ПО и проек-
тирования архитектур. Он занимает должность старшего архитектора решений
в AWS, возглавляя стратегические инициативы по проектированию и реа-
лизации облачных решений для корпоративных клиентов с использованием
полного комплекса сервисов AWS. Он тесно сотрудничает с кросс-функцио-
нальными командами, включая специалистов по продажам, разработчиков
24 Создатели книги
и продакт-менеджеров, для создания всеобъемлющих решений, превышающих
ожидания клиентов. Он также предоставляет клиентам технические консуль-
тации и передовые идеи, помогая им ориентироваться в сложных облачных
задачах и достигать бизнес-целей.
Основные компетенции Вираджа включают облачно-ориентированные архитек-
туры, микросервисы, бессерверные решения, Docker, Kubernetes, непрерывную
интеграцию (CI) / непрерывное развертывание (CD) и инфраструктуру как код
(1аС). Он прошел сертификацию AWS как архитектор и разработчик, выступал
на конференции re: Invent и редактировал публикации, посвященные облачным
технологиям. В сфере его интересов — построение автоматически масштаби-
руемых программных систем, проектирование облачно-ориентированных при-
ложений, а также пайплайнов CI/CD для сложных сред развертывания.
ВВЕДЕНИЕ
Книга «Solutions architect: архитектура и проектирование ИТ-решений» учит
читателей создавать надежные, масштабируемые, отказоустойчивые решения
с высокой доступностью. В ней описываются различные свойства архитектур
решений и особенности проектирования архитектур следующего поколения
для облачных сред.
Книга начинается с подробного рассмотрения архитектуры решений и роли архи-
тектора решений. Она проводит читателя по пути проектирования архитектуры
решений, предоставляя подробный обзор основных принципов проектирования,
нетривиальных паттернов и особенностей облачно-ориентированного проек-
тирования современных программных продуктов. Затем мы углубимся в темы
оптимизации производительности, безопасности, соответствия требованиям,
надежности, оптимизации затрат и операционного совершенства при проекти-
ровании решений.
В книге большое внимание уделено вопросам автоматизации безопасности,
инфраструктур, DevOps, аварийного восстановления и документирования ар-
хитектур решений. Также вы узнаете, как обеспечить актуальность архитектуры
для будущего за счет инженерии данных, машинного обучения и генеративного
ИИ. Книгу дополняет руководство по гибким навыкам (soft skills) для архитек-
торов решений и по методам непрерывного обучения.
Для кого эта книга
Книга предназначена для разработчиков ПО, системных инженеров, DevOps-
инженеров, архитекторов и технических лидеров, которые работают в отрасли IT
и стремятся стать архитекторами решений, а также для опытных архитекторов,
желающих проектировать безопасные, надежные, высокопроизводительные
и экономичные архитектуры.
26 Введение
О чем эта книга
Книга включает следующие главы.
Глава 1 «Архитекторы решений в организациях» исследует разнообразные роли
архитекторов решений в организациях, подробно объясняя их обязанности
и показывая, как они сочетаются с другими организационными структурами.
Глава 2 «Принципы проектирования архитектур решений» обсуждает фунда-
ментальные принципы, управляющие созданием масштабируемых, безопасных
и эффективных архитектур решений. Особое внимание уделяется лучшим
практикам методологии проектирования.
Глава 3 «Миграция на облачные платформы и проектирование облачных архи-
тектур» представляет план перехода на облачную платформу, включая страте-
гии миграции, преимущества перехода в облако и принципы проектирования
облачных архитектур.
Глава 4 «Паттерны проектирования архитектур решений» содержит обзор рас-
пространенных архитектурных паттернов. В ней представлены рекомендации
относительно того, когда и как следует эффективно применять их для решения
разнообразных архитектурных проблем.
Глава 5 «Паттерны проектирования облачно-ориентированных архитектур»
посвящена паттернам проектирования, предназначенным для облачно-ориен-
тированных сред. Особое внимание уделяется масштабируемости, устойчивости
и удобству обслуживания.
Глава 6 «Факторы производительности» выводит на первый план оптимизацию
работы ИТ-систем, с обсуждением ключевых метрик и стратегий повышения
скорости и эффективности в архитектурном проектировании.
Глава 7 «Факторы безопасности» уделяет особое внимание критическому аспекту
безопасности в архитектурах решений. В главе рассматриваются лучшие прак-
тики, паттерны и стратегии защиты систем.
Глава 8 «Факторы надежности архитектуры» изучает принципы и практики,
играющие важную роль при построении надежных систем, включая планиро-
вание аварийного восстановления и обеспечение высокой доступности.
Глава 9 «Операционное совершенство» выделяет стратегии и практики достиже-
ния операционного совершенства, обеспечивающие эффективность, надежность
и удобство обслуживания систем.
Глава 10 «Оптимизация затрат» содержит рекомендации по управлению затра-
тами, связанными с архитектурными решениями, и их оптимизации. Главный
критерий здесь — обеспечение максимальной пользы при минимальных расходах.
Глава 11 «DevOps и фреймворк архитектуры решений» посвящена интеграции
практик DevOps в архитектуру решений. В ней будет показано, какую пользу
приносит эта синергия для развертывания, мониторинга и обслуживания.
Как извлечь максимальную пользу из книги
27
Глава 12 «Инженерия данных для архитектур решений» знакомит читателя
с основными принципами инженерии данных в контексте архитектуры решений.
Особое внимание уделяется системам данных и рабочим процессам.
Глава 13 «Архитектура машинного обучения» рассматривает архитектурные
вопросы интеграции машинного обучения в различные решения, от подготовки
данных до развертывания модели.
Глава 14 «Архитектура генеративного ИИ» исследует архитектуру, лежащую
в основе систем генеративного ИИ. В ней обсуждаются компоненты и процессы,
позволяющие ИИ создавать новый контент.
Глава 15 «Переработка архитектуры унаследованных систем» предоставляет
стратегии и информацию для модернизации унаследованных (легаси) систем.
Речь пойдет о переходе на современные облачные среды.
Глава 16 «Документирование архитектуры решений» подчеркивает важность
и структуру подробной документации архитектур решений. В ней также
рассказано о том, как архитектору эффективно передать суть своей разработки.
Глава 17 «Гибкие навыки, которые нужны хорошему архитектору решений» по-
священа важнейшим гибким навыкам, необходимым для успеха архитекторов
решений, включая коммуникации, решение задач и лидерские качества.
Как извлечь максимальную пользу из книги
Усвоить материал книги поможет опыт проектирования программных архи-
тектур. Полезно иметь хотя бы общее представление о любом популярном
провайдере публичных облачных услуг — таком, как AWS. Тем не менее для
понимания материала книги никаких особых навыков в этой области не требу-
ется. Все необходимые примеры и инструкции приведены в соответствующих
главах. Книга представит основные концепции проектирования архитектур
решений, не требуя от читателя знания определенного языка программирования,
фреймворка или набора инструментов.
Условные обозначения
Ниже перечислены условные обозначения, которые используются в этой книге.
КодВТексте: таким шрифтом выделены фрагменты кода в тексте, имена таблиц
баз данных, имена файлов, расширения файлов, пути, фиктивные URL, поль-
зовательский ввод, идентификаторы. Например, «платформы 1оТ должны
поддерживать SigV4, Х.509 и специальную аутентификацию, предоставляя
детализированное управление доступом с политиками 1оТ до уровня тем
MQTT».
28
.Введение
Блок кода записывается в следующем виде:
// Инициализировать сумму нулем.
let sum = 0;
// Перебрать массив чисел.
for (let number of numbers) {
// Прибавить число к сумме,
sum += number;
}
// Вычислить среднее, разделив сумму на длину массива.
let average = sum / numbers.length;
// Вернуть среднее.
return average;
Полужирным шрифтом выделены новые термины, важные понятия или слова,
выводимые на экран (например, в меню или диалоговых окнах). Например, «Об-
лачные провайдеры — такие, как AWS, Microsoft Azure и GCP — предоставляют
много готовых решений, которые помогут вам модернизировать вашу систему».
Так выглядят предупреждения или важные примечания.
Так выглядят советы и рекомендации.
ГЛАВА 1
АРХИТЕКТОРЫ РЕШЕНИЙ
В ОРГАНИЗАЦИЯХ
Эта книга — исчерпывающее руководство по архитектуре программных реше-
ний, разработанное, чтобы помочь вам стать квалифицированным архитектором
решений. В главе 1 рассматриваются смысл архитектуры решений и ее важность
как основы для разработки решений в организациях. Архитектура решений
подразумевает проектирование мощной основы, включающей такие важные
области, как ИТ-инфраструктура, безопасность приложений, надежность и во-
просы эксплуатации.
Архитекторы решений работают в тесном контакте со стейкхолдерами проекта,
анализируя требования и прорабатывая ограничения в части затрат, бюджета,
сроков и комплаенса для создания полноценного решения.
Архитекторы решений также осуществляют активную поддержку продукта
после его выпуска, работая над обеспечением масштабируемости, доступности
и удобства обслуживания. Кроме того, они сотрудничают с отделом продаж для
продвижения продукта и его технических преимуществ.
В этой главе рассматриваются следующие темы.
• Что такое архитектура решений?
• Роль архитектора решений.
• Обязанности архитектора решений.
• Архитекторы решений в agile-организациях.
• Типичные проблемы, с которыми сталкивается архитектор решений.
• Карьерный путь и развитие навыков архитекторов решений.
К концу этой главы вы получите ценную информацию о роли архитекторов
решений и вызовах, с которыми они сталкиваются. Вы узнаете, как архитекто-
ры решений справляются с ограничениями и вносят свой вклад в техническое
видение и общий успех своей организации.
30 Глава 1. Архитекторы решений в организациях
Что такое архитектура решения?
Представление об архитектуре решения может различаться в зависимости от
точки зрения, принятой конкретными профессионалами или организациями.
Тем не менее по своей сути архитектура решения подразумевает определение
и планирование различных аспектов бизнес-решения с учетом стратегических
и тактических факторов.
Со стратегической точки зрения архитектор решений отвечает за разработку
долгосрочного видения. Оно гарантирует, что решение (программное обеспе-
чение) останется актуальным и сможет адаптироваться к будущим изменениям,
с возможностью расширения в соответствии с изменяющимися требованиями
пользователей и рабочей нагрузкой.
С тактической точки зрения архитектура решения концентрируется на непо-
средственных потребностях бизнеса. Она ориентирована на проектирование
приложения, способного справиться с текущей рабочей нагрузкой и эффективно
решать повседневные задачи организации.
Тем не менее архитектура решения — это не просто код. Она охватывает всю
систему, включая такие области, как системная инфраструктура, сеть, без-
опасность, требования комплаенса, эксплуатация системы, вопросы издержек
и надежность.
С учетом всех этих вопросов архитектор решений создает подробный план,
который направляет разработку и реализацию решения. План не только обес-
печивает удовлетворение текущих потребностей бизнеса, но и закладывает
основу для дальнейшего роста и успеха.
Преимущество архитектуры решения
Архитектура решения чрезвычайно важна по нескольким причинам. Прежде
всего она обеспечивает прочную основу для разработки корпоративных про-
граммных решений. По мере того как проекты разрастаются, а команды рас-
пределяются географически, наличие четко определенной архитектуры решения
гарантирует сохранение устойчивости и эффективности совместной работы
в долгосрочной перспективе.
Архитектура решения удовлетворяет разнообразные потребности решения с со-
хранением ориентации на общий бизнес-контекст. Она включает такие крити-
ческие элементы, как технологические платформы, компоненты приложений,
требования к данным, потребности в ресурсах и важнейшие нефункциональные
требования, или НФТ (или NFR, non-functional requirements). К числу НФТ
относятся масштабируемость, надежность, производительность, доступность,
безопасность и удобство обслуживания. При соблюдении этих требований архи-
тектура решения гарантирует, что разработанное решение будет удовлетворять
необходимым стандартам и ожиданиям.
Что такое архитектура решения? 31
На рис. 1.1 показаны потенциальные преимущества, которые получает
организация от участия архитектора решений в бизнесе.
Рис. 1.1. Преимущества архитектуры решения
На этой диаграмме выделены следующие преимущества хорошей архитектуры
решения.
• Соответствие технологии бизнес-требованиям: архитектор решений оце-
нивает, какие технологии следует внедрить в организацию или проект для
удовлетворения бизнес-требований и обеспечения устойчивости, удобства
обслуживания и необходимой квалификации команды в долгосрочной пер-
спективе.
• Оценка потенциала рынка: архитектура решения включает процесс анализа
и непрерывной оценки последних тенденций рынка, чтобы гарантировать,
что разработанное решение удовлетворяет потребности клиента и бизнеса.
Она также помогает создавать и продвигать новые продукты.
• Минимизация срыва целевых сроков: архитектор решений непрерывно
работает со всеми стейкхолдерами (ключевыми заинтересованными лица-
ми), включая бизнес-команду, клиентов и команду разработки. Он следит за
тем, чтобы общее решение соответствовало бизнес-целям и плану-графику
запуска и вероятность срыва целевых сроков была минимальной.
• Упрощение эффективной совместной работы: архитектура решения служит
общим ориентиром и инструментом взаимодействий для всех стейкхолдеров
32 Глава 1. Архитекторы решений в организациях
проекта. Она упрощает эффективную совместную работу бизнес-команд,
разработчиков, проектировщиков и других ключевых участников. Понятная
документация и наглядность архитектуры решения способствуют лучшему
пониманию, слаженности и организации принятия решений между членами
команды, гарантируя, что все одинаково понимают общие цели и работают
на их достижение.
• Масштабируемость и гибкость: в хорошо спроектированной архитектуре
решения масштабирование и гибкость становятся ключевыми факторами.
Они позволяют решению адаптироваться и плавно расти по мере эволюции
бизнеса и увеличения пользовательских нагрузок. Архитектура решения,
способная прогнозировать будущий рост и нацеленная на реализацию мер
масштабируемости, гарантирует, что система справится с растущими потреб-
ностями без значительных перебоев в работе или дорогостоящих изменений.
• Соответствие бизнес-целям: главной задачей проектирования архитектуры
решения являются удовлетворение потребностей стейкхолдеров и возмож-
ность адаптироваться к их требованиям. Архитектура решения преобра-
зует бизнес-цели в техническое видение посредством анализа рыночных
тенденций и реализации лучших практик. Архитектура решения должна
быть достаточно гибкой, чтобы соответствовать новым, нетривиальным
и стремительно изменяющимся бизнес-требованиям.
• Улучшенное планирование ресурсов: имея четко определенную архитек-
туру решения, организации могут точно определить тип и количество не-
обходимых ресурсов. Тем самым облегчается стратегическое планирование
человеческих ресурсов, обеспечивается достаточное финансирование и время
работы, гарантируется наличие специалистов необходимой квалификации
и оптимальное использование ресурсов, что ведет к более плавному ходу
проекта и соблюдению сроков.
• Улучшенное прогнозирование бюджета: для эффективного прогнозирования
бюджета крайне важно осуществлять тщательную оценку и анализ. Хоро-
шо определенная структура решения предоставляет понятную, доступную
информацию о том, какие ресурсы необходимы для завершения проекта.
Понимание деталей масштаба и требований позволяет организациям точнее
прогнозировать затраты и сокращает риск перерасхода бюджета.
• Снижение рисков: хорошая архитектура решения включает оценку рисков
и стратегии их снижения. За счет выявления потенциальных рисков на
более ранней стадии архитекторы решений могут реализовать меры, что-
бы снизить риски или избежать их. Такой проактивный подход помогает
свести к минимуму риски для графика проекта, бюджета и общего успеха.
Стратегии снижения рисков могут включать планы резервного копирования,
меры создания избыточности, факторы безопасности и планы аварийного
восстановления.
• Повышение окупаемости инвестиций: архитектура решения определяет
окупаемость и помогает оценить успех проекта. Она мотивирует бизнес
Роль архитектора решений 33
думать о способах сократить затраты и устранить потери за счет применения
автоматизации, что повышает общую окупаемость инвестиций.
• Определение сроков проекта: определение точных сроков проекта чрез-
вычайно важно для реализации решения. Архитектор решений выявляет,
какие ресурсы и усилия потребуются на этапе проектирования, что долж-
но помочь установить количество времени, необходимое для разработки
решений.
Итак, теперь у вас имеется общее представление об архитектуре решения и ее
преимуществах. Перейдем к рассмотрению роли архитектора решений и ее
влиянию на построение качественной архитектуры решения.
Роль архитектора решений
Если вас интересуют способы надлежащей организации и поставки решения,
знайте: архитектор решений играет важнейшую роль в их определении. Он
проектирует систему в целом и интеграцию разных систем между разными
группами. Архитектор решений определяет ожидаемый результат, работая
с бизнес-стейкхолдерами и обеспечивая четкое понимание технической коман-
дой целей поставки.
На рис. 1.2 представлена блок-схема жизненного цикла поставки решения. Архи-
тектор решений участвует во всех этапах проектирования и поставки решения.
Рис. 1.2. Жизненный цикл поставки решения
Как показано на диаграмме, жизненный цикл поставки решения включает сле-
дующие этапы с участием архитектора решения.
• Требования и вйдение бизнеса: архитектор решений работает с бизнес-
стейкхолдерами, чтобы понять их вйдение.
34
Глава 1. Архитекторы решений в организациях
• Анализ требований и техническое вйдение: анализ требований, определя-
ющий техническое вйдение для исполнения бизнес-стратегии.
• Прототипирование и рекомендации: архитектор решений выбирает техно-
логию, проводя проверку концепции (РОС, proof of concept) и демонстрируя
прототипы.
• Проектирование решения: архитектор решений разрабатывает решения
в соответствии со стандартами организации и в сотрудничестве с другими
заинтересованными группами.
• Разработка: архитектор работает с командой разработчиков над созданием
решения. Он становится связующим звеном между бизнесом и техническими
командами.
• Интеграция и тестирование: архитектор проверяет, что итоговое решение
работает в соответствии со всеми функциональными и нефункциональными
требованиями.
• Реализация: архитектор сотрудничает с командами разработки и разверты-
вания для создания беспроблемной реализации и помогает им справиться
со всеми возникающими сложностями.
• Эксплуатация и обслуживание: архитектор проверяет, что средства ведения
журналов и мониторинга функционируют, и по мере необходимости направ-
ляет работу команды по масштабированию и восстановлению после сбоев.
Общий жизненный цикл является итеративным процессом. Когда приложение
перейдет на продакшен и им начнут пользоваться, на основании обратной связи
от заказчиков могут возникнуть новые требования, которые отразятся на видении
будущих усовершенствований продукта.
Архитектор решений несет ответственность за решение следующих задач на
этапе проектирования:
• документирование стандартов решения;
• определение высокоуровневого дизайна решения;
• определение межсистемной интеграции;
• определение фаз решения;
• определение подхода к реализации;
• определение способа мониторинга и оповещений;
• документирование сильных и слабых сторон дизайна решения;
• документирование требований аудита и комплаенса.
Архитекторы решений не только отвечают за проектирование решения, но
и помогают руководителям проектов с оценкой ресурсов и издержек, определе-
нием сроков проекта и основных контрольных точек, а также релизом проекта
и составлением плана поддержки. Архитектор решений прорабатывает разные
фазы жизненного цикла решения, от проектирования до поставки и запуска.
Роль архитектора решений 35
Архитектор решений помогает команде разработки преодолевать препятствия,
делясь своим опытом и широким пониманием ситуации.
В зависимости от размера и сложности проекта архитекторов решений
в команде может быть несколько. В целом роль архитектора решений рас-
сматривается в книге на обобщенном уровне. Тем не менее на практике часто
встречаются архитекторы решений, занимающие разные должности в рамках
организации: архитектор корпоративных решений, архитектор программных
решений или технический архитектор. В этом разделе будут описаны неко-
торые особенности, присущие разным должностям. При этом обязанности
разных архитекторов решений могут частично совпадать в зависимости от
структуры организации.
Архитекторов решений можно разделить на архитекторов широкого профиля
и архитекторов специализированных решений. Архитекторы широкого про-
филя обладают обширными знаниями в различных технических областях. Они
отличаются полным пониманием различных областей архитектуры решений
и могут осуществлять комплексное руководство. С другой стороны, архитекторы
специализированных решений (SSA, Specialist Solution Architect) обладают
глубокими познаниями в конкретных областях: Big Data, безопасность, сети или
отраслевые предметные области. Они владеют специализированными знаниями
и могут быть техническими лидерами в зонах своей компетенции.
Во многих случаях архитектор широкого профиля сотрудничает с SSA при
определении требований и сложности проекта. Это позволяет использовать
углубленные знания специалистов, сохраняя целостность и надлежащую инте-
грированность общей архитектуры решения.
Присутствие в организации как архитекторов широкого профиля, так и SSA
делает возможным сбалансированный и разносторонний подход к архитектуре
решений. Оно гарантирует, что архитектурные решения и рекомендации будут
соответствовать потребностям проекта и базироваться как на широких, так
и на глубоких знаниях.
Объединяя навыки и опыт разных архитекторов решений, организации могут
эффективно решать специфические задачи и удовлетворять особые требования
в рамках проектов, что позволит им успешно проектировать и реализовывать
надежные решения.
Роли архитекторов широкого профиля
Такие специалисты широкого профиля играют ключевую роль в архитектуре
решений благодаря пониманию различных технических областей. Они обладают
разносторонними познаниями, которые позволяют им предоставлять рекомендации
и принимать обоснованные решения в разных сферах проектирования и реализа-
ции решений. Ниже перечислены типы ролей архитекторов широкого профиля.
36
Глава 1. Архитекторы решений в организациях
Архитектор корпоративных решений
Вы когда-нибудь задумывались, как происходит запуск продуктов в отрасли
информационных технологий? Здесь в игру вступают корпоративные реше-
ния — они определяют лучшие практики, культуру и подходящие технологии.
Архитектор корпоративных решений работает в тесном взаимодействии со
стейкхолдерами, экспертами в предметных областях и руководством, чтобы
определять организационные стратегии для информационных технологий и га-
рантировать, что его знания соответствуют бизнес-правилам компании.
Корпоративные архитекторы занимаются проектированием решений в мас-
штабах организации; они создают долгосрочные планы и решения вместе со
стейкхолдерами и руководством. Одной из самых важных задач становится
окончательный выбор технологий, которые будут использоваться компанией,
и наблюдение за последовательным и целостным применением этих технологий.
Другой важной задачей корпоративного архитектора является определение
бизнес-архитектуры. В некоторых организациях может встречаться должность
бизнес-архитектора. Бизнес-архитектура восполняет пробел между стратегией
в масштабах организации и ее успешным применением. Она помогает преоб-
разовать общую стратегию в конкретные исполняемые действия и переводит
ее на тактический уровень для реализации.
Ключевое различие между архитектором решений и архитектором корпо-
ративных решений заключается в содержании и направленности их работы.
Архитектор решений концентрируется на конкретных проектах или решениях,
проектируя и направляя реализацию приложений или систем в соответствии
с требованиями бизнеса и технологии. В их роли центральное место обычно
занимает проект, и они концентрируются на конкретных технологиях или
функциональных областях. Напротив, архитектор корпоративных решений
действует на стратегическом уровне, курируя общую ИТ-инфраструктуру
и стратегию организации. Он обеспечивает соответствие ИТ-стратегии бизнес-
целям, интегрируя результаты разных архитекторов решений из разных отделов.
Эта роль охватывает более широкий диапазон технологий и бизнес-процессов
и ориентируется на общий технологический ландшафт организации и ее стра-
тегическую направленность.
В целом архитекторы корпоративных решений сосредоточены на видении компа-
нии и обязанностях, касающихся определения стандартов успешной реализации
этого видения в масштабах организации.
Архитектор приложений
Архитектор приложений, иногда называемый программным архитектором,
играет жизненно важную роль в проектировании и разработке программного
обеспечения. Он взаимодействует с организацией для определения технических
Роль архитектора решений 37
подробностей проектов разработки. Задача архитектора приложений — обес-
печить соответствие программных продуктов лучшим отраслевым практикам
и стандартам организации. Архитекторы приложений работают с разными
командами, чтобы определить порядок интеграции с другими программными
модулями.
Например, для организации из сферы здравоохранения может быть важно,
чтобы новая система управления пациентами плавно интегрировалась с суще-
ствующими системами хранения электронных историй болезни, с соблюдением
как требований законодательства, так и внутренних протоколов. В финансовом
учреждении архитектор может курировать разработку нового банковского
приложения, гарантируя, что оно безопасно интегрируется с существующими
системами обработки транзакций и соответствует стандартам финансовой от-
расли. В обоих случаях архитектор приложений следит за тем, чтобы программ-
ный продукт не только отвечал функциональным целям, но и соответствовал
важнейшим стандартам отрасли и организации.
Одной из ключевых обязанностей архитектора приложения является управ-
ление техническими вопросами разработки ПО. Архитекторы контролируют,
чтобы проектируемые API имели грамотный дизайн и работали оптимальным
образом. Они также учитывают требования к масштабируемости, чтобы продукт
мог справиться с возрастающей рабочей нагрузкой.
Кроме того, архитектор приложений обеспечивает бесшовную интеграцию
с другими программными компонентами, чтобы упростить взаимодействие
с ними.
Архитектор приложений служит контактным лицом для обращения с тех-
ническими запросами от инженерной команды. Он выявляет проблемы
и предоставляет рекомендации по обеспечению беспроблемной эксплуатации
системы.
®Хотя в небольших проектах отдельного архитектора приложений может не
быть, его обязанности часто принимает на себя старший инженер, занимаясь,
таким образом, проектированием архитектуры продукта.
Кроме технической специализации, архитектор приложений берет на себя роль
ментора. Он поддерживает и направляет команду разработки, уделяя внимание
любым сложностям, возникающим в ходе интеграции команд или обусловлен-
ным бизнес-требованиями. Благодаря его тесному сотрудничеству с командой
обеспечиваются связность и успешность процесса разработки.
В целом архитектор приложений вносит свой вклад в общий успех проектов,
являясь техническим руководителем, обеспечивая соблюдение лучших практик
и поддерживая инженерную команду на протяжении всего жизненного цикла
разработки.
38 Глава 1. Архитекторы решений в организациях
Облачный архитектор
Роль облачного архитектора появилась только в последнее десятилетие, но
с ускорением перехода на облачные технологии в корпоративных средах стала
чрезвычайно востребованной. С переходом организаций в облако потребность
в профессионалах в области планирования, проектирования и управления об-
лачными средами как никогда увеличилась.
Облачные архитекторы отвечают за разработку и реализацию стратегий облач-
ных вычислений компании. Они обладают глубоким знанием разнообразных об-
лачных сервисов и могут проектировать решения, в полной мере задействующие
весь потенциал облачных платформ.
Работа в облаке стала очень популярной, и организации активно осуществляют
переход на публичные облачные сервисы. Ввиду популярности публичных
облачных платформ — таких, как Amazon Web Services (AWS), Microsoft
Azure и Google Cloud Platform (GCP) — облачные архитекторы стали играть
важнейшую роль в руководстве процессами принятия облачных технологий
в организациях. Роль облачного архитектора более подробно рассматривается
в главе 3 «Миграция на облачные платформы и проектирование облачных
архитектур».
Одной из ключевых задач облачного архитектора становится содействие органи-
зации в перенесении существующих рабочих нагрузок на облачную платформу.
Он разрабатывает полные стратегии миграции и проектирует гибридные об-
лачные архитектуры, которые обеспечивают гладкую интеграцию локальных
приложений с облачными ресурсами. Это позволяет организациям пользоваться
преимуществами масштабируемости, эффективности затрат и простоты управ-
ления, предоставляемыми облачными технологиями.
Для стартапов и бизнеса, начинающего в облаке с нуля, такой специалист может
спроектировать облачно-ориентированные архитектуры, оптимизированные
для облачных сред. Эти архитектуры применяют модель оплаты по мере ис-
пользования для оптимизации затрат и привлечения средств автоматизации,
предоставляемых облачной платформой.
Облачные технологии стали неотъемлемой частью современных корпоратив-
ных бизнес-стратегий. Чтобы добиться успеха и не отстать от стремительного
темпа инноваций и автоматизации, очень важно иметь опытного облачного
архитектора. Он играет важную роль в успехе компании, используя мощь об-
лачных технологий и раскрывая их потенциал, связанный с масштабированием,
эффективностью и ростом бизнеса.
Архите кто р-е ван гел ист
Появление архитекторов-евангелистов, также называемых технологически-
ми евангелистами, оказало значительное влияние на маркетинг, особенно
Роль архитектора решений 39
в контексте сложных платформ решений. В конкурентной среде люди ищут
совета экспертов, которые обладают глубокими знаниями и могут ответить на
вопросы, помогая принять обоснованные решения. Таким экспертом является
архитектор-евангелист с опытом в конкретной области.
Архитектор-евангелист играет важнейшую роль при проектировании архи-
тектур, ориентированных на требования заказчика и устраняющих болевые
точки. Он обладает глубоким пониманием архитектурных концепций, проблем
и рыночных тенденций и становится надежным советником для заказчиков
и партнеров. Его экспертные знания способствуют безопасному внедрению
конкретной платформы и росту прибыли благодаря расширению ее присут-
ствия на рынке.
Чтобы стимулировать принятие платформы целевой аудиторией, архитек-
торы-евангелисты создают публичный контент: блоги, официальные доку-
менты, статьи и т. д., а также участвуют в мероприятиях, включая отраслевые
саммиты, технические обсуждения и конференции. Проведение технических
семинаров и публикация обучающих руководств тоже входят в круг их за-
дач; с помощью этих средств они расширяют осведомленность аудитории
и генерируют интерес к своим продуктам. Архитекторы-евангелисты должны
обладать превосходными навыками письменного и устного общения. Не-
редко архитекторы решений берут на себя дополнительную обязанность по
пропаганде технологий.
В целом архитекторы-евангелисты являются инфлюенсерами, продвигающими
свои продукты и решения в широкой аудитории. Они применяют свой опыт и на-
выки коммуникации для общения с заказчиками, партнерами и сообществом,
в итоге способствуя принятию продукта, его росту и успеху на рынке.
Роли архитекторов специализированных решений
Кроме архитекторов широкого профиля, в мире архитектуры решений существу-
ют специализированные роли, зависящие от структуры организации и сложности
проекта. Эти SSA концентрируются на конкретных предметных областях, решая
специфические проблемы и удовлетворяя особые требования.
Конкретные роли и должности SSA зависят от специфики компании. В за-
висимости от проекта и сложности организации архитектор решений может
принимать на себя несколько ролей или разные архитекторы решений могут
иметь частично совпадающие обязанности. Суть в том, чтобы обеспечить
наличие в организации необходимого опыта и навыков в каждой области
и эффективно решать специфические проблемы и требования проекта. Рас-
смотрим примеры наиболее распространенных ролей архитекторов специа-
лизированных решений.
40 Глава 1. Архитекторы решений в организациях
Архитектор инфраструктуры
Архитектор инфраструктуры — специалист, главным образом занимающийся
проектированием корпоративной ИТ-инфраструктуры, безопасностью и рабо-
той дата-центров. Он тесно взаимодействует с архитекторами решений, чтобы
обеспечить соответствие инфраструктурной стратегии организации общим
бизнес-требованиям, и выделяет необходимые ресурсы для удовлетворения
этих потребностей на основании анализа как системных требований, так и суще-
ствующей среды. Кроме того, архитектор инфраструктуры помогает сократить
капитальные затраты и использовать сэкономленные средства для повышения
эффективности организации и рентабельности.
Архитектор инфраструктуры играет важнейшую роль в определении и плани-
ровании ИТ-ресурсов организации, от серверов хранения данных до отдельных
рабочих пространств. Он разрабатывает подробные планы обеспечения и раз-
вертывания ИТ-инфраструктуры, устанавливает программные стандарты,
а также координирует обновления системы и установку исправлений в масшта-
бах организации. К числу его ключевых обязанностей относится обеспечение
безопасности, так как архитектор должен принимать меры защиты всех сред от
потенциальных вирусных атак. В его обязанности также входят планирование
восстановления при авариях и резервное копирование системы, обеспечивающие
непрерывность бизнес-операций.
Примером вызова для архитекторов инфраструктуры является планирование
периодов пикового спроса в интернет-магазинах (День благодарения в США,
День подарков в Канаде и Великобритании, Дивали в Индии), когда множество
людей совершают покупки. Архитектор инфраструктуры должен подготовить
достаточно мощностей серверов и хранилища, чтобы справиться с пиковым
периодом, когда рабочая нагрузка может быть в 10 раз выше обычной; это уве-
личивает затраты на ИТ-инфраструктуру. Большую часть года вне пикового
сезона эта система будет простаивать.
Архитектору инфраструктуры необходимо планировать оптимизацию издер-
жек и взаимодействия с пользователем, и это еще одна причина, по которой он
может использовать облачные платформы для обеспечения дополнительной
емкости и масштабирования по требованию для сокращения издержек. Он дол-
жен следить за тем, чтобы системы были загружены, но при этом поддерживать
возможность роста при появлении новой функциональности.
В контексте облачных технологий архитектор облачной инфраструкту-
ры — специалист, который занимается проектированием и управлением ИТ-
инфраструктур на базе облачных платформ. Такие архитекторы обладают
глубоким знанием облачных платформ и сервисов, предоставляемых основными
провайдерами — такими, как AWS, Microsoft Azure и GCP.
Архитекторы облачной инфраструктуры работают в тесном взаимодействии
с организациями, чтобы определить оптимальную облачную архитектуру,
Роль архитектора решений 41
удовлетворяющую конкретные потребности в масштабируемости, эффек-
тивности издержек, безопасности и производительности. Они проектируют
и реализуют решения на базе облачных технологий, обеспечивая бесшовную
интеграцию с существующими системами и приложениями.
Архитекторы облачной инфраструктуры отвечают за планирование распреде-
ления ресурсов, управление облачными средствами безопасности и оптимиза-
цию облачной среды для оптимальной производительности и эффективности
затрат. Их опыт работы с облачными технологиями позволяет организациям
пользоваться преимуществами облачных вычислений и поддерживать надежную
и масштабируемую инфраструктуру.
В целом архитектор по инфраструктуре должен хорошо разбираться в работе
дата-центров и сопутствующих вопросах: нагрев, охлаждение, безопасность,
организация монтажа, серверы, хранение данных, резервное копирование,
установка и обновление программ, балансировщики нагрузки, виртуализация
ит. д.
Сетевой архитектор
Вы когда-нибудь задумывались, как крупным организациям с нескольки-
ми офисами или филиалами удается наладить успешную коммуникацию?
В этом им помогает сетевой архитектор, который занимается координацией
корпоративной стратегии сетевой коммуникации и воплощает в жизнь ИТ-
инфраструктуру.
Сетевой архитектор отвечает за проектирование компьютерных сетей, локальных
сетей (LAN), глобальных сетей (WAN), интерсетей, интрасетей и других ком-
муникационных систем. Он управляет организационными информационными
и сетевыми системами и обеспечивает низкую задержку передачи и высокую
производительность сети для повышения эффективности работы пользователей.
Он устанавливает безопасные соединения между рабочими местами пользова-
телей и внутренней сетью с использованием технологии виртуальных частных
сетей (VPN).
Сетевой архитектор тесно взаимодействует с архитектором инфраструктуры.
Иногда эти роли пересекаются, обеспечивая связность всех ИТ-инфраструктур.
Он работает с командой безопасности и проектирует файрвол организации
для защиты от вредоносных атак. Он отвечает за мониторинг и защиту сети
посредством отслеживания пакетов, сканирования портов и установки систем
обнаружения сетевых атак (IDS, Intrusion Detection System) и систем предот-
вращения сетевых атак (IPS, Intrusion Prevention System). Вы больше узнаете
о системах IDS/IPS в главе 7 «Факторы безопасности».
Сетевой архитектор должен оставаться в курсе новейших сетевых стратегий,
операций и технологий безопасной передачи данных с использованием VPN. Он
настраивает балансировщики нагрузки, проводит оптимизацию маршрутизации
42 Глава 1. Архитекторы решений в организациях
DNS (Domain Name System) и реализует объединение ИТ-инфраструктур. Его
работа напоминает построение сложной сети соединений, гарантирующей глад-
кое и эффективное движение данных внутри организации.
Архитектор данных
В эпоху стремительного роста объема информации роль архитектора данных
становится все более важной. Только задумайтесь — в каждом спроектиро-
ванном решении центральное место занимают данные, будь то информация
о клиенте, подробное описание продукта или выводы, полученные на основе
анализа сложных наборов данных. Так как объемы данных продолжают расти
по экспоненте, от гигабайтов до терабайтов и выше, эффективное управление
данными и архитектура данных начинают играть крайне важную роль. Должность
архитектора данных может называться, например, архитектор по аналитике или
архитектор по большим данным. (Я не называю архитектора баз данных, так как
его область ответственности ограничена структурированными данными в таких
реляционных БД, как Oracle и (RDS, Amazon Relational Database System).)
Традиционно данные хранились в структурированных реляционных базах
данных. Однако с увеличением количества неструктурированных данных
из таких источников, как социальные сети, интернет вещей (IoT, Internet of
Things) и журналы приложений, ситуация изменилась. Появились архитекторы
данных — визионеры, формирующие стратегию данных организации. Они от-
вечают за определение правил, политик, стандартов и моделей, управляющих
типами данных, собираемых и используемых в базе данных организации. Они
проектируют, создают архитектуру данных и управляют ею, обеспечивая ста-
бильную производительность и качество.
Архитектор данных работает совместно с различными стейкхолдерами, включая
руководящий административный персонал, аналитиков, инженеров данных,
дата-сайентистов и команды разработки. Он взаимодействует с широким кругом
лиц, от руководителей, применяющих средства бизнес-аналитики (BI, Business
Intelligence) для визуализации данных, до дата сайентистов, пользующихся
методами машинного обучения (МО). Цель архитектора данных — удовле-
творение потребностей организации в данных и предоставление пользователям
ценной аналитики.
Исходя из сказанного выше, диапазон обязанностей архитектора данных
очень широк. Он выбирает подходящую технологию БД, определяет варианты
хранения для структурированных и неструктурированных данных, управляет
потоковой и пакетной обработкой данных, а также проектирует озера данных
(data lake) как централизованные хранилища данных. Кроме того, он обеспечи-
вает безопасность данных, соответствие стандартам и шифрование для защиты
конфиденциальной информации. Другие области, в которых архитектор данных
может проявить свой опыт, — построение хранилищ данных, проектирование
витрин данных (data mart) и преобразование данных.
Роль архитектора решений 43
С ростом значимости машинного обучения в корпоративных средах начали
формироваться роли специализированных архитекторов МО. Такие специа-
листы плотно сотрудничают с архитекторами данных с целью проектирования
и реализации МО-алгоритмов и моделей, выводящих аналитику на основе
данных на следующий уровень.
В условиях непрекращающегося развития технологий архитектор данных должен
оставаться в курсе новейших тенденций в области БД, инструментов BI и средств
безопасности. Его опыт в инженерии данных и архитектуре прокладывает путь
к эффективному использованию данных, позволяя организациям раскрыть
полный потенциал ресурсов данных.
Архитектор машинного обучения
В эру искусственного интеллекта (ИИ) и машинного обучения роль архитек-
тора МО приобрела колоссальную важность. По мере того как организации
все больше задействуют МО в своих решениях, появилась насущная необхо-
димость в экспертах, способных проектировать и реализовывать надежные
архитектуры МО.
Архитекторы МО отвечают за применение системного мышления для реализа-
ции и включения МО в корпоративный программный стек. Они анализируют
и выбирают наиболее подходящие инструменты и технологии для МО и реа-
лизаций на базе ИИ на основании требований организации. Они формируют
архитектуру данных для поддержки МО, обеспечения эффективного поглоще-
ния (ingestion) данных, их обработки и хранения для обучения и аналитической
обработки.
Одна из ключевых обязанностей архитектора МО заключается в измене-
нии существующего программного стека и инфраструктуры для бесшовной
интеграции возможностей МО. Это, в частности, включает внедрение МО-
фреймворков, библиотек и API в существующую экосистему, возможность
эффективной предварительной обработки данных, обучение моделей и их
развертывание.
Эксплуатация решений МО — еще одна важнейшая обязанность МО-
архитектора. Он разрабатывает механизмы непрерывного мониторинга и усо-
вершенствования моделей МО, обеспечивающих оптимальную производитель-
ность, точность и надежность с течением времени. Архитекторы МО плотно
сотрудничают с дата-сайентистами, инженерами данных и разработчиками,
чтобы обеспечить бесшовное развертывание и масштабирование моделей МО
в рабочих средах.
Архитекторы МО должны глубоко разбираться в лучших практиках архитектуры,
методах оптимизации производительности, вопросах безопасности, требова-
ниях комплаенса, стратегиях оптимизации издержек, а также операционного
совершенства в контексте решений ИИ и МО. Они проектируют архитектуры,
44
Глава 1. Архитекторы решений в организациях
соответствующие этим принципам, с учетом облачной ориентации современных
технологических стеков МО.
В главе 13 этой книги мы подробно исследуем архитектуру МО, рассмотрим
основные принципы и нетривиальные паттерны проектирования, антипаттерны
и облачно-ориентированные аспекты современных технологических стеков ИИ
и МО. Вы получите знания и навыки, необходимые для проектирования и раз-
вертывания надежных и масштабируемых решений МО.
Машинное обучение преобразует целые отрасли и прокладывает путь иннова-
циям в разных сферах. Организации активно пользуются преимуществами МО,
поэтому роль архитектора МО стала исключительно важной для раскрытия
всего потенциала ИИ и МО и достижения успехов бизнеса.
Архитектор генеративного ИИ
Кроме МО, особым вниманием пользуется еще одна активно развивающаяся
область — генеративный искусственный интеллект, или генеративный ИИ
(GenAI). Генеративный ИИ концентрируется на создании интеллектуальных
систем, которые обладают когнитивными возможностями, сходными с чело-
веческими, и могут решать широкий спектр задач в различных предметных
областях.
Архитекторы генеративного ИИ отвечают за проектирование и разработку
продвинутых ИИ-систем, которые выходят за рамки конкретных сценариев ис-
пользования. Они изучают такие передовые технологии, как глубокое обучение,
обучение с подкреплением, обработка естественного языка и компьютерное
зрение для построения интеллектуальных систем, способных к рассуждениям,
обучению и адаптации в реальном времени.
Архитекторы генеративного ИИ применяют свой опыт в нейронных сетях,
когнитивистике и вычислительных моделях для создания архитектур, позволя-
ющих машинам понимать сложные данные, принимать решения и решать задачи
способом, моделирующим человеческий интеллект. Они плотно сотрудничают
с междисциплинарными командами, включающими дата-сайентистов, специа-
листов по computer science и экспертов в предметной области для создания
полного решения на основе генеративного ИИ.
При проектировании архитектуры генеративного ИИ приходится иметь дело
с вопросами этики, а также справляться с неопределенностью и неоднознач-
ностью. Архитекторы генеративного ИИ направляют усилия на построение
систем, которые могут учиться на ограниченных данных, передавать знания
между предметными областями и демонстрировать стабильную эффективность
в динамических и непредсказуемых средах.
В главе 14 этой книги мы погрузимся в завораживающий мир архитектур ге-
неративного ИИ и исследуем принципы, методы и проблемы, связанные с по-
строением интеллектуальных систем. Вы узнаете о новейших достижениях,
Роль архитектора решений 45
архитектурных парадигмах и этических аспектах генеративного ИИ, что позволит
вам проектировать и разрабатывать интеллектуальные системы, выходящие за
рамки обычных возможностей ИИ.
Так как область ИИ продолжает развиваться, генеративный ИИ обладает не-
вероятным потенциалом для преобразования целых отраслей, революционных
достижений в автоматизации и наделения машин возможностями выполне-
ния сложных задач, которые ранее считались уделом только человеческого
разума. Архитекторы генеративного ИИ играют важнейшую роль в выборе
направления этого преобразования и формировании будущего интеллекту-
альных систем.
Интеграция МО и генеративного ИИ в архитектуру решений открывает
потрясающие возможности для интеллектуальной автоматизации,
персонализации опыта и революционных инноваций в разных областях.
Архитектор по безопасности
В современном цифровом мире безопасность данных организаций и систем вы-
ходит на первый план. Роль архитектора по безопасности становится ключевой
для проектирования и реализации надежных средств для защиты от потен-
циальных угроз и уязвимостей.
Для соблюдения безопасности в организации архитектор по безопасности со-
трудничает с разными командами и внешними разработчиками. Он отвечает за
проектирование и развертывание соответствующих решений для сетей и ком-
пьютеров, защиту информационных систем, сетей и веб-сайтов компании. Кроме
того, он играет ключевую роль в тестировании уязвимостей, анализе рисков
и аудитах безопасности для выявления потенциальных слабостей и выработки
стратегий их преодоления.
К обязанностям архитекторов по безопасности относится рецензирование
и одобрение установки файрволов, VPN, маршрутизаторов, а также другие меры
безопасности. Он проводит тщательное тестирование процессов безопасности
для того, чтобы проверить их эффективность и предоставить техническое руко-
водство для команд безопасности. Соответствие отраслевым стандартам и нор-
мам — один из важнейших аспектов его роли; оно гарантирует, что приложения
будут придерживаться необходимых протоколов безопасности, а данные будут
правильно зашифрованы и доступны.
Архитектор по безопасности обладает глубоким пониманием технологий без-
опасности, инструментов и отдельных приемов. Он также хорошо разбирается
в проектировании полноценных архитектур безопасности, охватывающих дан-
ные, сеть, инфраструктуру и приложения. Опыт и знания архитекторов играют
важную роль в защите организации от кибер-угроз, а также в проверке конфи-
денциальности, целостности и доступности конфиденциальной информации.
46
Глава 1. Архитекторы решений в организациях
В главе 7 этой книги мы займемся соображениями безопасности, исследуем
важнейшие принципы, лучшие практики и формирующиеся тенденции в ар-
хитектуре безопасности. Вы также получите представление о методологиях
оценки рисков, реализации средств обеспечения безопасности и воспитании
соответствующей культуры в организациях. Понимая роль архитекторов без-
опасности и нюансы проектирования, вы будете готовы к построению надежных
архитектур безопасности, укрепляющих защиту организаций от потенциальных
угроз и защищающих их ценные ресурсы.
Архитектор DevOps
В современной динамичной и высококонкурентной среде организации ищут
возможности оптимизировать процессы разработки и эксплуатации, чтобы по-
ставлять приложения быстрее, эффективнее и качественнее. В этом отношении
на первый план выходит роль архитектора DevOps.
DevOps — методология сотрудничества, которая связывает команды разработки
и эксплуатации и позволяет организовать беспроблемную совместную работу.
Архитектор DevOps играет ключевую роль в развитии этого сотрудничества
и реализации практик и инструментов, автоматизирующих различные параметры
жизненного цикла разработки продукта.
Одной из ключевых обязанностей архитектора DevOps является формирование
и оптимизация пайплайнов непрерывной интеграции и непрерывного развер-
тывания (CI/CD, Continuous Integration / Continuous Deployment). Архитекто-
ры DevOps автоматизируют процессы сборки, тестирования и развертывания,
чтобы гарантировать, что изменения в коде будут тщательно тестироваться
и бесперебойно развертываться в рабочих средах. Автоматизация этих процессов
позволяет организациям сократить количество ошибок, ускорить цикл выпуска
и повысить надежность поставки продуктов.
Инфраструктура как код (IaC, Infrastructure as Code) — еще одна важная зона
ответственности архитектора DevOps. Архитектор использует такие инстру-
менты, как Chef, Puppet, Ansible и Terraform, для определения и автоматизации
предоставления и настройки инфраструктурных ресурсов. Это упрощает коман-
дам разработки и эксплуатации создание, репликацию и управление средами,
обеспечивая большую гибкость и масштабируемость.
Мониторинг и оповещения также принадлежат к числу важных компонентов
надежной архитектуры DevOps. Архитектор DevOps планирует и реализует
решения мониторинга, которые непрерывно отслеживают инциденты в работе
приложения, инфраструктуры и безопасности. Автоматизированные оповеще-
ния создаются для оперативного уведомления соответствующих команд при
возникновении проблем или серьезных изменений, что обеспечивает быстрое
реагирование и устранение проблемы.
Роль архитектора решений 47
Восстановление в аварийных ситуациях — одна из критических областей ответ-
ственности архитектора DevOps. Архитектор проектирует и реализует стратегии
развертывания, которые гарантируют, что организации смогут восстановиться
после сбоев или экстренных ситуаций с минимальными потерями данных
(параметр «целевая точка восстановления» (RPO, Recovery Point Objective))
и простоем (параметр «целевое время восстановления» (RTO, Recovery Time
Objective)). Упреждающее планирование восстановления в аварийных ситуа-
циях позволяет организациям минимизировать последствия потенциальных
нарушений и сохранить бесперебойность работы бизнеса.
В главе 11 этой книги мы исследуем принципы, методологии и инструменты,
используемые в DevOps, и разберемся, как интегрировать практики DevOps
в архитектуру решения. Осваивая DevOps под руководством опытного архитек-
тора, организация может повысить эффективность командной работы, ускорить
поставку продукта и добиться большей гибкости в современной динамичной
технологической среде.
Отраслевой архитектор
Отраслевой архитектор — это специалист, который работает над проектированием
решений, адаптированных для конкретной отрасли или вертикали. Такие специа-
листы обладают глубокими знаниями и опытом в конкретной области и хорошо
понимают специфические проблемы, требования и правила, связанные с нею.
Отраслевой архитектор должен тесно сотрудничать со стейкхолдерами, вклю-
чая высшее руководство, экспертов в предметной области и технологические
команды, чтобы лучше понимать конкретные потребности и цели отрасли. Он
анализирует отраслевые тенденции, зарождающиеся технологии и лучшие
практики, чтобы разрабатывать архитектурные стратегии, соответствующие
целям отрасли.
Отраслевой архитектор отвечает за преобразование бизнес-требований в техниче-
ские решения под конкретные отраслевые задачи. Он проектирует и разрабатывает
внутриотраслевые приложения, системы и платформы, удовлетворяющие специ-
фическим потребностям отрасли. При этом он должен учитывать такие факторы,
как комплаенс, конфиденциальность данных, масштабируемость и совместимость.
Кроме того, отраслевой архитектор несет ответственность за то, чтобы органи-
зация не отставала от инноваций и достижений в отрасли. Он непрерывно оце-
нивает новые технологии, инструменты и фреймворки, которые могут улучшить
текущую работу и дать конкурентное преимущество.
Навыки совместной работы и коммуникаций крайне важны для отраслевого
архитектора, так как ему приходится тесно взаимодействовать с разными
стейкхолдерами, включая высшее руководство, разработчиков, аналитиков
данных и регулирующие органы. Он выступает доверенным консультантом,
48 Глава 1. Архитекторы решений в организациях
предоставляя аналитику и рекомендации по принятию технологий, архитектур-
ным решениям и инициативам цифровой трансформации в отрасли.
Используя свой опыт в отрасли и знания архитектуры, отраслевой архитектор
способствует росту, эффективности и цифровой трансформации организаций,
работающих в конкретных секторах. Он играет ключевую роль в обеспечении
соответствия технологических решений отраслевым стандартам, нормам, пра-
вилам и лучшим практикам, что в конечном счете способствует внедрению
инноваций и успеху в отрасли.
Несколько примеров отраслевых архитекторов в конкретных секторах.
• Отраслевой архитектор в области финансов: специализируется на техноло-
гических решениях для финансовых учреждений, понимании сложных норм
и стандартов и потребностей в безопасности. Он разрабатывает решения для
управления рисками, обнаружения мошенничества и обеспечения комплаенса
в финансовом секторе.
• Отраслевой архитектор в производстве: проектирует решения для произ-
водственных секторов (например, автомобильной промышленности или
производства потребительских товаров), уделяя первоочередное внимание
оптимизации цепочек поставок, планированию производства и промышлен-
ному интернету вещей для повышения эффективности и производительности.
• Отраслевой архитектор в розничной торговле: разрабатывает техноло-
гические решения для розничной торговли, включая POS-системы, CRM
и омниканальные взаимодействия. Первоочередное внимание уделяет
безопасности данных, а также интеграции физических и цифровых каналов
розничной торговли.
• Отраслевой архитектор в области здравоохранения: занимается разработкой
решений в сфере медицины, проектируя системы для ведения электронных
медицинских карт, управления пациентами и телемедицины. Решает про-
блемы конфиденциальности, безопасности и комплаенса в области здраво-
охранения.
Мы рассмотрели лишь некоторые примеры отраслевых архитекторов и секторов,
в которых они специализируются. В каждой отрасли существуют уникальные
проблемы, требования и технологическая среда, и отраслевые архитекторы
играют важную роль в проектировании специализированных решений, удо-
влетворяющих специфические потребности этой отрасли.
Роль SSA выходит за рамки отраслей и технологических предметных областей.
В нее входят конкретные поставщики SaaS — такие, как Salesforce, ServiceNow,
Databricks и Snowflake, а также корпоративные приложения от SAP, VMware,
Microsoft, Oracle и таких облачных платформ, как AWS, GCP и Azure. Рас-
смотреть все возможные роли SSA в одном разделе достаточно сложно, поэтому
Обязанности архитектора решений 49
мы сосредоточились на общей концепции роли, подчеркивая ее разнообразие
и широкий спектр специализаций в этой области.
После знакомства с разнообразием ролей архитекторов решений перейдем
к рассмотрению их обязанностей.
Обязанности архитектора решений
Архитектор решений является техническим руководителем, взаимодействующим
с заказчиком, что обусловливает наличие у него широкого круга обязанностей.
Главная обязанность архитектора решений — преобразование бизнес-видения
организации в техническое решение и создание связи между стейкхолдерами из
сфер бизнеса и технологий. Архитектор решений использует обширный техноло-
гический и коммерческий опыт, чтобы обеспечить успешную поставку решения.
Обязанности архитектора решений могут несколько отличаться в зависимости
от природы организации. В организациях, занимающихся консультированием,
архитектор решений часто выделяется под конкретный проект и заказчика,
тогда как в организациях, занимающихся созданием продуктов, архитектор
решений может работать с несколькими заказчиками, обучая их продукту
и оценивая дизайн их решений.
Архитектор решений имеет разные обязанности на разных стадиях цикла раз-
работки приложения, даже еще до запуска проекта. В фазе предварительного
планирования проекта архитектор решений работает с бизнес-стейкхолдерами
для подготовки и оценки документа RFR (Request For Response) (запрос на
решение).
После запуска проекта архитектор решений анализирует требования, чтобы
принять решение о возможности его технической реализации, одновременно
определяя такие нефункциональные требования (НФТ), как масштабируемость,
высокая доступность, производительность и безопасность. Архитектор решений
понимает различные ограничения проекта и выбирает технологию, разрабатывая
подтверждения концепции (РОС, Proof Of Concept).
После начала разработки архитектор решений выполняет функции наставника
команды разработки и корректирует как технические, так и бизнес-потребности.
После запуска приложения архитектор решений проверяет, что оно работает
в соответствии с заданными НФТ, и определяет следующую итерацию на ос-
новании обратной связи от пользователей.
В этом разделе вы больше узнаете о роли архитектора решений на разных
стадиях жизненного цикла разработки продукта. В целом архитектор решений
выполняет обязанности, представленные на рис. 1.3.
50 Глава 1. Архитекторы решений в организациях
Разработка РоС
и прототипа
Понимание
ограничении
архитектуры
Понимание
и вовлечение
стейкхолдеров
Масштабиро-
вание решения,
технологический
евангелист
Проектирование
и поставка
решения
Определение
требований
Анализ
функциональных
требований
Рис. 1.3. Модель обязанностей архитектора решений
нефункциональных
Обязанности архитектора
решений
Выбор
технологии
Как видно из схемы, архитектор решений имеет множество обязанностей. В сле-
дующих разделах они рассматриваются подробнее.
Анализ функциональных требований (ФТ)
На начальной стадии любого проекта определение бизнес-требований стано-
вится важнейшим основанием для дизайна решения. Их первичное базовое
представление обусловливает необходимость привлечения разносторонней
команды, включая участников с техническим опытом, с тем чтобы в точности
определить и понять эти требования. Изначально требования устанавливаются
бизнес-стейкхолдерами. По мере технологического развития проекта часто воз-
никает необходимость в их корректировке. В таких ситуациях роль архитектора
решений выходит на первый план не только в отношении проектирования при-
ложения, но и в формировании общего бизнес-результата.
Архитекторы решений не ограничиваются техническими знаниями; они ис-
пользуют глубокое понимание бизнеса и добиваются того, чтобы технология
Обязанности архитектора решений 51
соответствовала целям бизнеса. Они тесно взаимодействуют с руководителями
проектов и стейкхолдерами, связывая функциональные требования (ФТ) с тех-
ническими решениями и выступая доверенными консультантами. Они играют
ключевую роль в видении конечного продукта и его реализации и направляют
проект так, чтобы он не только соответствовал техническим спецификациям,
но и отвечал стратегическим целям бизнеса и удовлетворял ожидания поль-
зователей.
По сути роль архитектора решений не ограничивается традиционными рамками
технических знаний. Он помогает ликвидировать разрыв между техническими
возможностями и реалиями бизнеса, стремясь, чтобы итоговое решение не
только соответствовало техническим спецификациям, но и приносило реальную
ценность для бизнеса. Умение архитектора решений работать с различными
стейкхолдерами, понимать тонкости потребностей бизнеса и предвидеть потен-
циальные проблемы делает его незаменимым проводником на пути от концепции
до реализации проекта. Успех проекта часто зависит от умения архитектора
решений преобразовывать сложные требования в связную, функциональную
и эффективную архитектуру решения.
Функциональные требования (ФТ) указывают, что должна делать система,
с подробным описанием поведения, функций и возможностей, которые должно
поддерживать приложение. Они напрямую относятся к взаимодействию с поль-
зователями и задачам, которые будет выполнять приложение.
Нефункциональные требования (НФТ) определяют, как система должна вы-
полнять некоторые функции, задают атрибуты качества системы (такие, как
производительность, удобство использования, надежность и безопасность). Эти
требования описывают условия эксплуатации системы и ограничения, влияю-
щие на опыт взаимодействия с пользователями, но не на конкретное поведение.
Давайте познакомимся с НФТ поближе и посмотрим, как архитекторы решений
помогают их определить.
Определение НФТ
НФТ не всегда видны пользователям и заказчикам непосредственно, но их
отсутствие может отрицательно повлиять на общий опыт взаимодействия
с пользователями и навредить бизнесу. НФТ включают такие критические ха-
рактеристики системы, как производительность, задержка, масштабируемость,
высокая доступность и восстановление при аварийных ситуациях. Наиболее
распространенные НФТ представлены на рис. 1.4.
Для определения НФТ архитекторы решений отвечают на следующие вопросы.
• Производительность:
Каким будет время загрузки приложения для пользователей?
Как решить проблему сетевой задержки?
52 Глава 1. Архитекторы решений в организациях
• Безопасность и комплаенс:
Как защитить приложение от несанкционированного доступа?
Как защитить приложение от атак злоумышленников?
Как обеспечить соблюдение местных законов и требований аудита?
• Восстанавливаемость:
Как восстановить приложение в случае сбоя?
Как свести к минимуму время восстановления в случае сбоя?
Как восстановить потерянные данные?
• Удобство обслуживания:
Как организовать мониторинг и выдачу оповещений в приложении?
Как обеспечить поддержку приложения?
• Надежность:
Как убедиться в согласованности поведения приложения?
Как обнаруживать и исправлять дефекты?
Производи-
тельность
Безопасность
и комплаенс
Удобство
использова-
ния
Доступность
Восстанавли-
ваемость
Удобство
обслуживания
Надежность
Рис. 1.4. НФТ в дизайне решения
Обязанности архитектора решений 53
• Доступность:
Как обеспечить высокую доступность приложения?
Как обеспечить отказоустойчивость приложения?
• Масштабируемость:
Как удовлетворить повышенную потребность в ресурсах?
Как обеспечить масштабирование при непредвиденном скачке нагрузки?
• Удобство использования:
Как упростить работу с приложением?
Как обеспечить бесперебойный пользовательский опыт?
Как сделать приложение доступным для разных групп пользователей?
®В зависимости от природы проекта некоторые НФТ могут быть актуальны
только для конкретного проекта (например, четкая различимость голоса для
решений, предназначенных для контакт-центров).
Вы узнаете больше об этих характеристиках в главе 2 «Принципы проектиро-
вания архитектур решений».
Архитектор решений начинает участвовать в проекте на очень ранней стадии,
а это означает, что он должен спроектировать решение, собрав требования от
всех стейкхолдеров в организации. Архитектор решений должен обеспечить
согласованность дизайна решения между разными системными компонентами
и требованиями. Он отвечает за определение НФТ между разными компонента-
ми и группами, поскольку должен обеспечить достижение желаемого удобства
использования по всем параметрам.
НФТ — неотъемлемая и существенная часть дизайна решения, которую нередко
упускают из виду, когда команды слишком сильно сосредоточены на бизнес-
требованиях, а это может отразиться на взаимодействии с пользователями.
Хороший архитектор решений должен донести важность НФТ и убедиться, что
их реализация включена в поставку решения.
Понимание и вовлечение стейкхолдеров
Ключевым заинтересованным лицом, или стейкхолдером, называется любое
лицо, заинтересованное в проекте (прямо или косвенно). Кроме заказчиков
и пользователей, стейкхолдерами также могут быть команды разработки,
продаж, маркетинга, инфраструктуры, сетей и поддержки, а также группа
финансирования проекта. Стейкхолдеры могут быть внутренними или внешними
по отношению к проекту. К внутренним относятся команда проекта, спонсоры,
сотрудники и старший менеджмент; к внешним — заказчики, поставщики, парт-
неры, акционеры, аудиторы и действующее правительство страны.
Стейкхолдеры часто по-разному понимают одну и ту же бизнес-задачу в зави-
симости от контекста, в котором они находятся; например, разработчик может
54
Глава 1. Архитекторы решений в организациях
рассматривать бизнес-требование с точки зрения программирования, а ауди-
тор — с позиций безопасности и комплаенса.
Чтобы обеспечить успех проекта, архитектор решений должен работать как
с техническими, так и с нетехническими стейкхолдерами. Он должен понимать
требования к проекту с разных точек зрения, вследствие чего ему приходится
общаться с разными группами. При этом ему приходится объяснять сложные
технические концепции для нетехнических стейкхолдеров и принимать меры
к тому, чтобы техническая команда понимала бизнес-цели. Сотрудничая со всеми
участвующими сторонами, архитектор решений следит за тем, чтобы техниче-
ское решение соответствовало более широким бизнес-целям. Такая совместная
работа крайне необходима для создания полноценного и эффективного решения,
удовлетворяющего потребности всех сторон.
Архитектор решений обладает превосходными навыками коммуникации
и ведения переговоров, что помогает ему выбрать оптимальный путь с учетом
всех остальных мнений. Архитектор решений выступает связующим звеном
между техническими и нетехническими специалистами и устраняет разрывы
в коммуникации между ними. Часто такие разрывы становятся причиной про-
вала проекта. Представители бизнеса рассматривают ситуацию с точки зрения
функциональности и возможностей продукта, тогда как команда разработки
стремится построить как можно более технически совместимое решение, что
иногда затрагивает нефункциональную сторону проекта.
Архитектор решений должен убедиться в том, что обе команды находятся на
одной волне, а предлагаемая функциональность технически осуществима. Он
выполняет функции ментора для технической команды и по мере необходимо-
сти руководит ею, а также объясняет технические концепции простым языком,
понятным всем остальным.
Архитектурные ограничения
Архитектурные ограничения — одна из самых сложных составляющих дизайна
решений. Архитектурные ограничения значительно усложняют проектирование,
поскольку ограничивают гибкость и инновационность. Чтобы новые решения
оставались технически совместимыми с существующими системами в рамках
этих ограничений, потребуются немалые усилия и ресурсы. Кроме того, ограни-
чения, относящиеся к бюджету, ресурсам и срокам, могут повлиять на качество
и масштаб решения. Поддерживать баланс между соблюдением отраслевых
стандартов и требований законодательства и реализацией функциональных
потребностей достаточно сложно.
Архитектор решений должен внимательно управлять архитектурными ограни-
чениями и иметь возможность обсуждать их, чтобы найти оптимальное реше-
ние. Часто эти ограничения зависят друг от друга, и особое внимание к одному
ограничению может повысить важность других. Самые распространенные
ограничения представлены на рис. 1.5.
Обязанности архитектора решений 55
Рис. 1.5. Архитектурные ограничения при дизайне решения
При проектировании решения должны учитываться следующие ограничения.
• Затраты:
Какой объем финансирования доступен для реализации решения?
Какая рентабельность предполагается?
• Качество:
Насколько близко результат соответствует ФТ и НФТ?
Как обеспечить и отслеживать качество решения?
• Время:
Когда должен быть поставлен результат?
Возможна ли корректировка срока поставки?
• Масштаб:
Каковы точные ожидания бизнеса и требования заказчика?
Как преодолеть разрыв в требованиях при проектировании?
56
Глава 1. Архитекторы решений в организациях
• Технология:
Какую технологию можно использовать?
Какую гибкость обеспечит использование унаследованных технологий
по сравнению с новыми?
Следует ли заниматься разработкой собственными силами или доверить
ее внешнему подрядчику?
• Риск:
Что может пойти не так и как справиться с возможными проблемами?
Какой риск считают допустимым стейкхолдеры?
• Ресурс:
Что необходимо для завершения поставки решения?
Кто будет работать над реализацией решения?
• Комплаенс:
Какие требования местного законодательства могут повлиять на решение?
Какие требования действуют в области аудита и сертификации?
Архитектор решений должен соблюдать баланс ограничений и анализировать
возможные компромиссы по каждому из них; например, экономия затрат за счет
сокращения ресурсов может повлиять на срок поставки.
Соблюдение сроков при ограниченных ресурсах может повлиять на качество,
что, в свою очередь, приведет к увеличению затрат из-за непредвиденных ис-
правлений ошибок. Таким образом, важно найти баланс между затратами, каче-
ством, временем и масштабом. Расползание масштаба (scope creep) — одна из
самых сложных ситуаций, с которой может столкнуться архитектор решений,
потому что это может отрицательно сказаться на всех остальных ограничениях
и повысить риски для поставки решения.
Расползанием масштаба называется постепенное расширение целей
и результатов проекта, часто без соответствующего увеличения ресурсов,
времени или бюджета.
Очень важно, чтобы архитектор решений понимал особенности всех ограничений
и имел возможность выявлять любые возникающие при этом риски. Он должен
принять планы преодоления рисков и выдержать баланс между ними. Возмож-
ность справиться с расползанием масштаба заметно помогает со своевременной
поставкой проекта.
Выбор технологии
Выбор технологии — ключевая задача архитектора решений, с которой может
быть связана наибольшая сложность. Диапазон доступных технологий огромен,
и архитектор решений должен найти подходящие технологии для решения.
Обязанности архитектора решений 57
Архитектор решений должен иметь обширные и глубокие познания в области
технологий, чтобы принять наилучшее решение, так как выбранный им техно-
логический стек может повлиять на итоговую поставку продукта.
Любая задача имеет много решений в широком диапазоне технологий. Чтобы
сделать правильный выбор, архитектор решений должен учитывать ФТ и НФТ,
а также определить критерии выбора технологии. Выбранная технология должна
учитывать другие перспективы независимо от цели, будь то возможность инте-
грации с другими фреймворками и API или соблюдение требований к произво-
дительности и потребностей в области безопасности.
Архитектор решений должен быть способен выбрать технологию, которая не
только удовлетворяет текущие требования, но и масштабируется для будущих
требований.
Проверка концепции и прототип
Создание прототипа, пожалуй, самая интересная часть работы архитектора
решений. Чтобы подобрать надежную технологию, архитектор решений дол-
жен провести проверку концепции (РОС) в разных технологических стеках
и проанализировать пригодность стеков для ФТ и НФТ решения. При построе-
нии РОС архитектор решений стремится определить структурные элементы
решения.
Идея разработки РОС заключается в оценке технологии на наборе критических
функциональных реализаций, что облегчит выбор технологического стека на
основании его возможностей. РОС имеет короткий жизненный цикл, а ее при-
менение ограничивается оценкой экспертов в команде или организации.
После оценки нескольких платформ с использованием РОС архитектор решений
может переходить к построению прототипа для технологического стека. Про-
тотип разрабатывается в демонстрационных целях и передается заказчику для
обоснования финансирования. РОС и прототипы далеки от уровня итогового
продукта; сборки от архитектора решений имеют ограниченную функциональ-
ность, что может усложнить разработку решения.
Проектирование и поставка решения
Архитектор приступает к решению после того, как поймет особенности ФТ, НФТ
и существующие ограничения, а также после выбора технологии. В agile-среде
этот процесс итеративный; требования могут изменяться со временем, и эти
изменения будут влиять на проектируемое решение.
Архитектор должен спроектировать решение, которое не потеряет актуально-
сти со временем (future-proof). Оно должно состоять из надежных структурных
элементов и быть достаточно гибким, чтобы адаптироваться к изменениям,
обусловленным потребностями пользователя или усовершенствованиями
58 Глава 1. Архитекторы решений в организациях
технологии. Например, если пользовательский спрос увеличится на порядок,
приложение должно быть способно масштабироваться и адаптироваться
к новому объему без значительных изменений в архитектуре. Точно так же,
если для решения проблемы будет задействована новая технология (напри-
мер, МО или блокчейн), архитектура должна быть способна адаптироваться
к ним — например, с использованием ИИ для построения рекомендательной
системы на базе существующих данных в приложении электронной коммер-
ции.
Архитектор решений должен уделять внимание значительным изменениям
в требованиях и применять планы снижения рисков.
В качестве примера архитектуры, которая останется актуальной в будущем,
можно рассмотреть слабосвязанную архитектуру микросервисов на базе RESTful
API. Такие архитектуры могут расширяться для новых требований и достаточно
просто интегрироваться. О других вариантах архитектур можно прочитать в гла-
ве 4 «Паттерны проектирования архитектур решений» и в главе 5 «Паттерны
проектирования облачно-ориентированных архитектур».
Работоспособность и обслуживание после запуска
Даже после запуска решения архитектор решений продолжает играть важную
роль в обеспечении работоспособности продукта. Чтобы справиться с ростом
пользовательской базы и нагрузки на продукт, архитектор решений должен
знать, как масштабировать продукт для удовлетворения спроса и обеспечить
высокую доступность без ущерба для пользователей.
В случае непредвиденных событий (например, сбоев питания) архитектор реше-
ния руководит действиями разных команд (инфраструктурной, ИТ-поддержкой
и командой развертывания) при отработке плана аварийного восстановления,
чтобы бизнес-процессы не прерывались. Архитектор решений должен выдер-
живать цели организации в части показателей RPO и RTO. RPO определяет,
какую часть данных организация может позволить себе потерять, и выражается
в объеме данных, теряемых на протяжении сбоя, — например, потерю данных
за 15 минут. RTO определяет, сколько времени должно потребоваться системе
для возврата к нормальной работе. Вы больше узнаете о RTO и RPO в главе 11
«DevOps и фреймворк архитектуры решений».
В случае проблем с производительностью, обусловленных ростом спроса,
архитектор решений помогает масштабировать систему по горизонтали, чтобы
справиться с узкими местами приложения, или вертикально для сглаживания
узких мест базы данных. Механизмы масштабирования и самовосстановле-
ния более подробно рассматриваются в главе 8 «Факторы надежности архи-
тектуры».
Архитектор решений в Agile-организациях 59
Архитектор решений планирует адаптацию к любым новым требованиям к су-
ществующему продукту, обусловленным особенностями его использования или
любыми другими причинами. Он может вносить изменения в НФТ на основа-
нии данных мониторинга поведения пользователей; например, пользователи
покидают страницу, если ее загрузка занимает более трех секунд. Архитектор
решений прорабатывает подобные вопросы и руководит командой, устраняющей
проблемы, которые могут возникнуть после релиза.
Масштабирование решений и технологический
евангелизм
Евангелизм — самая интересная задача архитектора решений. Архитектор ре-
шений ускоряет принятие продукта и платформы, распространяя информацию
о них на общедоступных площадках. Он ведет блоги о реализации решения
и проводит семинары для демонстрации потенциальных преимуществ и при-
менения технологических платформ.
Таким образом он обеспечивает поддержку технологии и помогает установить
отраслевой стандарт. Архитектор решений должен быть энтузиастом технологии.
Чтобы являться ее евангелистом, он должен обладать отличными навыками
письменной речи и публичных выступлений.
Архитектор решений в Agile-организациях
Модель Agile становится очень популярной. Она в значительной мере отходит
от традиционных методологий управления проектами. В отличие от традицион-
ной водопадной модели, использующей линейный и последовательный подход,
Agile уделяет особое внимание гибкости, совместной работе и адаптируемости.
В Agile применяется итеративная разработка: проекты делятся на небольшие
части, которые удобно часто пересматривать и адаптировать. Этот подход по-
ощряет непрерывную обратную связь и участие заказчика во всем жизненном
цикле проекта — в отличие от жесткой структуры традиционной модели и ее
склонности к получению обратной связи только на конкретных стадиях. Вслед-
ствие своей динамической природы модель Agile особенно хорошо подходит для
проектов, в которых требования ожидаемо будут изменяться или не полностью
определены в начале работы.
Что первым приходит вам в голову, когда вы думаете об участии архитектора
решений в модели Agile? По этому поводу существует множество мифов — на-
пример, считается, что архитектура решений — очень сложное дело и в Agile
вам придется представить дизайн сразу же или на следующем спринте. Другой
миф утверждает, что архитектура Agile не обладает необходимой устойчиво-
стью для такого способа проектирования и разработки или что ее невозможно
тестировать.
60 Глава 1. Архитекторы решений в организациях
Архитектор решений в среде Agile должен следовать концепции итеративного
пересмотра архитектуры, анализируя свое решение и адаптируя его под изме-
нения требований. Дело сводится к выбору подходящего решения для корпо-
ративной среды, отладке коммуникаций, непрерывному получению обратной
связи и адаптивному моделированию. Команде разработки нужна прочная
архитектурная основа и способность адаптироваться к изменяющимся требова-
ниям; им необходимы руководство и наставничество от архитектора решений.
Архитектура Agile подразумевает снижение стоимости изменений, устранение
лишних требований после их пересмотра и создание фреймворка для быстрой
отмены некорректных требований. Agile-архитектор строит прототипы, по-
зволяющие понять и, как следствие, минимизировать риски и планируемые
изменения. При проектировании прототипов он соблюдает баланс потребно-
стей всех стейкхолдеров и создает слабосвязанную архитектуру, которая легко
интегрируется с другими модулями.
Agile рекомендует проектировать слабосвязанные и расширяемые интерфейсы,
а также внедрять автоматизацию, быстрое развертывание и мониторинг. Для
построения слабосвязанных решений архитектор может применять архитек-
туры микросервисов, а для быстрого развертывания — средства автоматизации
фреймворков тестирования с пайплайном непрерывного развертывания. О дру-
гих слабосвязанных архитектурных паттернах вы узнаете в главе 4 «Паттерны
проектирования архитектур решений».
Типичные сложности в работе архитектора
решений
Роль архитектора решений интересна и динамична, но и она не обходится без
сложностей. Понимание таких сложностей и умение их преодолевать абсолютно
необходимы для успеха в этой роли.
Перечислим некоторые из них.
• Баланс между бизнес-требованиями и техническими требованиями: архи-
тектор решений должен выдерживать баланс между удовлетворением целей
бизнеса и технической жизнеспособностью решения. Для этого необходимо
понимать как потребности бизнеса, так и технические возможности и нахо-
дить оптимальное решение.
• Управление сложностью: архитектор решений часто работает со сложными
системами и технологиями, которые может быть непросто понять и интегри-
ровать. Ему приходится ориентироваться в сложных технических средах,
применять разные компоненты и обеспечивать бесшовное взаимодействие
между ними.
• Хорошее знание технологических достижений: технологии постоянно
развиваются, регулярно появляются новые инструменты, фреймворки
Типичные сложности в работе архитектора решений 61
и методологии. Архитектор решений должен быть в курсе новейших до-
стижений и отраслевых тенденций, чтобы предоставлять инновационные
и эффективные решения.
• Работа со стейкхолдерами: архитектор решений работает с различными
стейкхолдерами, включая руководителей бизнеса, разработчиков, руководи-
телей проекта и конечных пользователей. Управлять разными ожиданиями,
требованиями и приоритетами бывает непросто. Навыки эффективной ком-
муникации, совместной работы и ведения переговоров крайне важны для
удовлетворения разнообразных потребностей стейкхолдеров.
• Решение проблем масштабируемости и производительности: архитектор ре-
шений должен проектировать решения, способные справляться с возрастаю-
щими объемами данных, пользовательскими нагрузками и изменяющимися
требованиями бизнеса. Обеспечение масштабируемости, производительности
и надежности очень важно, так как решения должны адаптироваться к буду-
щему росту без потери эффективности.
• Безопасность и комплаенс: безопасность данных и соблюдение регулиру-
ющих норм играют очень важную роль в современных цифровых средах.
Архитектор решений должен внедрять в свои решения надежные средства
безопасности, методы шифрования и специализированные фреймворки
для защиты конфиденциальных данных и соблюдения отраслевых стан-
дартов.
• Разрешение конфликтующих требований: у различных стейкхолдеров часто
возникают конфликты требований или приоритетов. Архитектор решений
должен разбираться в этих конфликтах, анализировать плюсы и минусы
разных вариантов и выбирать компромисс, удовлетворяющий общим целям
решения.
• Управление ограничениями проекта: архитектор решений должен уметь
работать в условиях ограниченных бюджетов, сроков и ресурсов. Он должен
принимать обоснованные решения, оптимизировать распределение ресурсов
и адаптироваться к изменяющейся динамике проекта, чтобы обеспечить
успешную поставку решения.
• Миграция на облачные технологии: с ростом популярности облачных вы-
числений архитектор решений часто сталкивается с проблемой эффективного
использования облачных платформ и сервисов. Он должен понимать нюансы
облачной архитектуры, моделей развертывания и инструментов, специфи-
ческих для компании-разработчика, чтобы проектировать масштабируемые
и экономичные решения на базе облачных технологий.
• Непрерывное обучение и повышение квалификации: вследствие стремитель-
ного развития технологий архитектор решений должен выделять время для
непрерывного обучения и повышения квалификации. Ему следует приобретать
новые знания, совершенствовать свою техническую квалификацию и быть
в курсе лучших практик отрасли, чтобы не утратить эффективность в работе.
62 Глава 1. Архитекторы решений в организациях
Если архитектор решений будет знать об этих проблемах и заранее прини-
мать меры для их решения, он сможет избежать сложностей и поставлять
успешные решения, соответствующие как бизнес-целям, так и техническим
требованиям.
Карьерный путь и развитие навыков
архитектора решений
Карьерный путь архитектора решений зависит от организации, отрасли и инди-
видуальных устремлений. В этом разделе рассматривается общее направление
карьерного пути и развития навыков для архитекторов решений.
Карьерный путь
Карьерный путь архитектора решений обычно подразумевает постепенный рост
до все более значимых позиций.
• Образование: чтобы начать карьеру архитектора решений, обычно тре-
буется иметь диплом бакалавра в области computer science, программной
инженерии или другой смежной области. При этом очень важна хорошая
подготовка в области разработки ПО, проектировании систем и знание
концепций ИТ.
• Профессиональный опыт: архитекторы решений обычно начинают свою
карьеру в качестве разработчиков, аналитиков систем или технических
консультантов. Накопление практического опыта проектирования и реали-
зации программных решений помогает сформировать отличное понимание
практической разработки приложений и ИТ-инфраструктуры.
• Проектирование решений и архитектура: по мере карьерного роста про-
фессионалы переходят к ролям, связанным с проектированием решений
и архитектурой. Они тесно взаимодействуют со стейкхолдерами, анализируют
бизнес-требования и проектируют масштабируемые, надежные и экономи-
чески эффективные решения. Им также пригодится опыт использования
методологий и схем архитектуры решений — таких, как TOGAF (The Open
Group Architecture Framework) или Zachman Framework.
Развитие навыков
Чтобы повысить свои карьерные перспективы, архитекторам решений следует
приложить усилия для развития навыков в следующих областях.
• Технические знания: архитектору решений необходим широкий спектр
технических навыков в разных областях — разработке приложений, управ-
лении базами данных, сетях, облачных вычислениях, безопасности и т. д. Он
должен непрерывно расширять свои технические знания, чтобы быть в курсе
новейших технологий и тенденций в отрасли.
Карьерный путь и развитие навыков архитектора решений 63
• Коммуникация и совместная работа: эффективные навыки коммуникации
и совместной работы исключительно важны для архитекторов решений.
Архитектор должен быть способен объяснять технические концепции
в терминах, понятных нетехническим стейкхолдерам, быть фасилитатором
в дискуссиях и формировать консенсус. Развитие сильных навыков комму-
никации и лидерства чрезвычайно важно для эффективной работы с кросс-
функциональными командами.
• Деловые качества: архитектор решений должен координировать техно-
логические решения с бизнес-целями. Развитие деловых качеств помогает
ему лучше понять стратегии организации, динамику отрасли и потребности
заказчика. Архитектор должен быть способен проанализировать влияние
технологических решений на бизнес в целом и дать соответствующие ре-
комендации.
• Лидерство и управление: по мере развития карьеры архитектор решений
может выступать руководителем и менеджером, отслеживая работу команд
архитекторов или управляя проектами поставки решений. Развитие навыков
управления проектами, руководства командами и стратегического планиро-
вания способствует умению добиваться успешного результата.
• Непрерывное обучение: сфера технологии постоянно развивается, и архи-
текторы решений должны проактивно стремиться к знаниям. Очень важно
постоянно оставаться в курсе появляющихся технологий, лучших отраслевых
практик и новых архитектурных паттернов. Прохождение сертификаций
и участие в отраслевых конференциях и семинарах способствует непрерыв-
ному профессиональному развитию.
В современной цифровой среде облачные вычисления стали неотъемлемой
частью архитектур решений. Облачные платформы обеспечивают масштабиро-
вание, гибкость и экономическую эффективность, делая возможными быстрое
развертывание и масштабирование приложений. Они также открывают доступ
к таким современным технологиям, как искусственный интеллект, анализ
больших данных и 1оТ, играющим ключевую роль в стратегиях цифровой
трансформации. Таким образом, хорошее знание облачных решений поможет
архитектору проектировать эффективные, конкурентоспособные решения,
которые останутся актуальными в будущем.
Перечислим ключевые знания и сертификаты в сфере облачных технологий,
которыми должен обладать архитектор решений.
• Облачные платформы: облачный архитектор должен быть знаком с основ-
ными облачными платформами — такими, как Amazon Web Services (AWS),
Microsoft Azure и Google Cloud Platform (GCP). Он должен знать основные
сервисы, архитектурные паттерны, варианты масштабирования и средства
безопасности, предоставляемые этими платформами.
• Облачная архитектура: архитекторы решений должны хорошо разбираться
в проектировании архитектур на базе облака. В частности, это подразумевает
64
Глава 1. Архитекторы решений в организациях
проектирование решений с высокой доступностью и масштабируемостью,
реализацию отказоустойчивых систем, а также оптимизацию затрат и про-
изводительности в облачных средах.
• Облачная безопасность: безопасность — одно из важных условий облачных
вычислений. Архитектор решений должен знать лучшие практики облачной
безопасности, механизмы шифрования, управление идентификацией и до-
ступом, а также стандарты соответствия, специфические для облачных сред.
Кроме того, важно понимать, как проектируются и реализуются безопасные
облачные архитектуры.
• Облачные хранилища и базы данных: архитектор решений должен хоро-
шо понимать варианты хранения данных в облаке — хранилища объектов,
блоков и файлов — и уметь выбирать подходящее решение в зависимости
от конкретных требований. Кроме того, архитектору пригодятся знания об-
лачных сервисов баз данных — таких, как Amazon RDS, Azure SQL Database
и Google Cloud Spanner.
• Облачные сертификаты: облачные сертификаты проверяют знания
специалиста по облачным технологиям; их наличие способствует более
высокому уровню доверия к специалисту. К числу популярных облач-
ных сертификатов для архитекторов решений относятся AWS Certified
Solutions Architect, Microsoft Certified: Azure Solutions Architect Expert
и Google Cloud Certified — Professional Cloud Architect. Эти сертификаты
демонстрируют профессиональный уровень в проектировании и реализа-
ции решений на базе облака.
Наличие знаний и сертификатов в облачных технологиях не только расширяет
набор профессиональных навыков архитектора решений, но и демонстрирует
его способность проектировать и реализовывать масштабируемые, надежные
и безопасные решения на базе облака. Оно повышает профессиональный
уровень доверия и конкурентоспособность специалиста в отрасли, которая
все больше ориентируется на облачные технологии. Если вам захочется
больше узнать о карьере архитектора облачных решений на основе AWS, об-
ращайтесь к книге «AWS for Solutions Architects» (https://www.amazon.com/
gp/product/180323895X/).
Итоги
В этой главе мы рассмотрели роль архитектора решений в организации и под-
робно разобрали его обязанности, навыки и сложности, встречающиеся в работе.
Сначала мы определили понятие архитектуры решения и отследили его развитие
со временем, а также подчеркнули его значимость для обеспечения успеха про-
екта и соответствия технических решений бизнес-целям.
Итоги 65
В главе представлены различные роли архитектора решений — как широкого
профиля, так и специализированные. Для каждой роли было приведено краткое
описание, раскрывающее специфические обязанности и знания.
Затем были подробно рассмотрены важнейшие обязанности архитектора реше-
ний: анализ требований пользователей, определение НФТ, общение со стейк-
холдерами, управление архитектурными ограничениями, выбор подходящих
технологий, разработка РОС, проектирование и поставка решений, обеспечение
работоспособности и обслуживания после запуска, а также евангелизм техно-
логий.
В этой главе также уделено внимание интеграции архитекторов решений в коман-
ды Agile. При этом подчеркивалась важность совместной работы, адаптируемости
и непрерывного улучшения в рамках процесса Agile-разработки.
Перечислены типичные проблемы, с которыми сталкиваются архитекторы ре-
шений, и даны рекомендации по их эффективному решению. Мы подчеркнули
необходимость непрерывного профессионального развития и совершенство-
вания навыков, чтобы не отстать от развивающихся технологий и отраслевых
тенденций.
Эта глава, в которой подробно рассматриваются основные характеристики роли
архитектора решений, станет руководством как для начинающих, так и для
практикующих профессионалов. Представленный обзор закладывает основу
для всестороннего исследования архитектуры решений.
В следующих главах мы обсудим принципы проектирования масштабируемых,
устойчивых и высокопроизводительных архитектур. Они касаются таких важных
вопросов, как применение мер безопасности, планирование в условиях архи-
тектурных ограничений и реализация изменений посредством тестирования
и автоматизации.
ГЛАВА 2
ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ
АРХИТЕКТУР РЕШЕНИЙ
В этой главе мы рассмотрим самые важные и распространенные принципы
проектирования и свойства архитектуры решений. Хотя здесь наше внимание
будет сосредоточено на ключевых элементах проектирования, стоит заметить,
что в зависимости от сложности продукта и конкретной предметной области
могут возникать дополнительные особенности. По мере чтения книги вы более
глубоко изучите фундаментальные принципы и свойства, в том числе те, что
применяются в разработке различных паттернов, предназначенных для разных
сценариев и ситуаций.
Мы поговорим в этой главе о принципах проектирования масштабируемых
и устойчивых архитектур, отличающихся оптимизированной производитель-
ностью, но при этом использующих надежные меры безопасности для защиты
приложения. Мы исследуем стратегии планирования в условиях архитектур-
ных ограничений, а также стратегии внедрения изменений через тестирование
и автоматизацию, уделяя особое внимание подходу к проектированию на основе
данных. Если вы будете понимать и применять эти принципы, у вас будет все
необходимое, чтобы мыслить критически и принимать обоснованные решения,
повышающие эффективность и надежность дизайна архитектуры.
В этой главе рассматриваются следующие темы.
• Построение масштабируемой архитектуры.
• Построение архитектуры, обладающей высокой доступностью и отказоу-
стойчивостью.
• Проектирование с учетом производительности.
• Создание неизменяемых архитектур.
• Слабая связанность.
• Сервисы, а не серверы.
• Проектирование на основе данных.
• Забота о безопасности на всех уровнях.
• Создание удобных и доступных приложений.
• Построение future-proof расширяемых архитектур.
• Архитектурная интероперабельность и портируемость.
Построение масштабируемых архитектур 67
• Повсеместное внедрение автоматизации.
• Планирование непрерывности бизнеса.
• Преодоление архитектурных ограничений.
Начнем с исследования фундаментальных элементов проектирования архитек-
туры. К концу этой главы вы получите достаточно знаний о ключевых особенно-
стях проектирования, которые следует учитывать при разработке архитектуры.
Эти знания станут важной вехой на вашем пути к пониманию и реализации
эффективных и надежных архитектурных решений.
Построение масштабируемых архитектур
Масштабируемость всегда была одним из важнейших факторов проектирования.
Если вы попросите любую организацию описать внедренные в ней решения,
одним из главных свойств этих решений, скорее всего, будет названа масштаби-
руемость. Масштабируемостью называется способность системы справляться
с растущими рабочими нагрузками, которые могут применяться к нескольким
уровням — серверам приложений, веб-приложениям и базам данных. Масшта-
бируемость помогает выполнять запросы пользователей без последствий для
производительности приложения, что приводит к повышению прибыли для
бизнеса.
Так как большинство приложений в наши дни строится на базе веб-технологий,
также стоит поговорить об эластичности (elasticity). Этим термином обознача-
ются способность системы к росту за счет добавления новой функциональности
и ее сокращение в целях избегания лишних затрат. С принятием публичных об-
лачных платформ появилась возможность быстро повышать и понижать рабочую
нагрузку, а эластичность пришла на смену масштабируемости.
Традиционно существовали два режима масштабирования.
• Горизонтальное масштабирование: его популярность выросла за последнее
десятилетие, когда вычислительные ресурсы стремительно дешевели. При
горизонтальном масштабировании подключают больше серверов для обра-
ботки повышающейся нагрузки, как показано на рис. 2.1.
Представим, что ваше приложение способно обработать 1000 запросов в секунду
двумя экземплярами на серверах. С ростом пользовательской базы приложение
начинает получать 2000 запросов в секунду, и это означает, что придется удво-
ить количество экземпляров приложения (доведя его до четырех), чтобы оно
справлялось с повышенной нагрузкой.
• Вертикальное масштабирование: применяется уже давно. При этой прак-
тике для обработки повышенных рабочих нагрузок на имеющиеся серверы
добавляют дополнительное пространство хранения данных и памяти. Как
показано на рис. 2.2, при вертикальном масштабировании вы получаете
более мощные серверы (вместо добавления новых серверов) для обработки
повышенной нагрузки.
68 Глава 2. Принципы проектирования архитектур решений
Рис. 2.1. Горизонтальное масштабирование
Рис. 2.2. Вертикальное масштабирование
Модель вертикального масштабирования может быть менее экономичной; затра-
ты на оборудование с дополнительной вычислительной мощностью и памятью
растут экспоненциально. По достижении определенного порога от вертикального
масштабирования стоит отказаться, если только оно не стало единственным воз-
можным вариантом из-за высоких затрат и ограничений на количество серверов.
Вертикальное масштабирование — более распространенный способ масштаби-
рования серверов реляционных баз данных. Впрочем, при достижении сервером
Построение масштабируемых архитектур 69
порога вертикального масштабирования стоит подумать о шардировании
(sharding) базы данных, так как она не сможет преодолеть ограничения памяти
и вычислительной мощности.
®Шардирование - метод масштабирования БД, основанный на разделении
и распределении данных между несколькими серверами. Данные разбиваются
по значению ключа шарда, который определяет, каким образом они будут
распределены между шардами. При вертикальном шардировании ключом
сегмента может быть конкретный столбец или группа столбцов в таблице.
Масштабирование может быть упреждающим, если у вас есть информация
о рабочей нагрузке, как это обычно бывает, или же реактивным, если возникнет
неожиданный пик или вам еще не приходилось иметь дела с такой нагрузкой.
Упреждающее масштабирование (predictive scaling) — продвинутый способ
управления рабочими нагрузками приложений, особенно в сценариях с пред-
сказуемым трафиком (как, например, на сайтах интернет-магазинов). Анализи-
руя исторические данные, организации могут прогнозировать закономерности
трафика и соответственно регулировать свои ресурсы .
Трафик на сайте интернет-магазина может различаться в зависимости от дня
недели, времени суток или праздников, что обусловливает применение стратегии
масштабирования, принудительно корректирующей ресурсы для обработки ожи-
даемой нагрузки. Такой подход не только оптимизирует использование ресурсов,
но и улучшает взаимодействие с пользователями за счет сокращения задержки
и предотвращения простоев. Это особенно важно при выбросах трафика, когда
распределение ресурсов может отставать от спроса.
Другой вид масштабирования — реактивное (reactive) — играет важную роль
для преодоления непредвиденных всплесков трафика, которые могут заметно
превышать норму и инициироваться такими событиями, как краткосрочные
распродажи. Понимание специфических паттернов трафика для разных стра-
ниц веб-сайта, а также навигации пользователя очень важно для эффективного
управления выбросами. Определяя, какие страницы могут кэшироваться или
какие запросы требуют интенсивного чтения, организации могут стратегически
выводить трафик с веб-уровня, используя сети распространения контента (CDN)
для управления статическим контентом.
Такое сочетание упреждающего и реактивного масштабирования обеспечивает
устойчивость и быстрый отклик приложения независимо от колебаний трафика.
Например, у показанной на рис. 2.3 группы Auto Scaling максимальный размер
составляет шесть экземпляров, а минимальный — три экземпляра. При обыч-
ном пользовательском трафике рабочая нагрузка будет обслуживаться тремя
работающими серверами, но количество серверов может достигать шести при
пиках трафика. Парк серверов должен расширяться в соответствии с политиками
масштабирования, определенными для корректировки количества экземпляров.
70 Глава 2. Принципы проектирования архитектур решений
ЕН ЕЮ Ш L
Группа Auto Scaling
Минимальное количество серверов Серверы, доступные для масштабирования по необходимости
----------------1---------------
Максимальное количество серверов
Рис. 2.3. Автоматическое масштабирование серверов
Например, политика может добавлять один сервер, когда загрузка процессора
превышает 60 % в парке существующих серверов, но их общее количество не
может превысить шесть.
Независимо от того, будет ли масштабирование упреждающим или реактивным,
необходимо отслеживать состояние приложения и собирать данные для плани-
рования потребностей в масштабировании.
Масштабирование статического контента
Статический контент (графика, видео и т. д.) играет важнейшую роль в привлече-
нии пользователей на веб-сайты. Тем не менее при неправильном управлении эти
элементы могут значительно замедлить работу приложения. Чтобы обеспечить
оптимальную скорость и взаимодействие с пользователем, важно организовать
эффективное масштабирование и распределение статического контента.
Для примера возьмем сайт интернет-магазина. Скорее всего, для каждого то-
вара будут добавлены несколько изображений (а может, даже видеороликов),
представляющих внешний вид товара и его использование. Это означает, что
сайт будет содержать значительный объем статического контента, создающего
нагрузку с интенсивным чтением, потому что большую часть времени пользова-
тели будут просматривать товары. Кроме того, пользователи могут отправлять
графику и видеоролики в обзорах или отзывах на товары.
Хранение статического контента на веб-сервере означает затраты большого
объема памяти хранилища, и с расширением списка товаров придется беспоко-
иться о масштабировании хранилища. Другая проблема заключается в том, что
статический контент хранится в файлах большого размера, что может создать
значительную задержку с загрузкой на стороне пользователя. Для решения этой
проблемы уровень веб-архитектуры должен использовать сеть распространения
контента, или CDN (Content Distribution Network). Сети CDN помогают кэши-
ровать контент ближе к пользователю, сокращая задержку и ускоряя загрузку.
Построение масштабируемых архитектур 71
Правильное масштабирование статического контента обеспечивает быстроту
и отзывчивость приложения, а это означает беспроблемное взаимодействие
с пользователем даже в условиях роста объема трафика.
Поставщики CDN (такие, как Akamai, Amazon CloudFront, Microsoft Azure
CDN и Google CDN) создают по всему миру сеть центров, в которых статиче-
ский контент может кэшироваться на веб-сервере, находящемся поблизости
от пользователя, что приводит к сокращению задержки. В главе 4 «Паттерны
проектирования архитектур решений» вы больше узнаете о кэшировании.
Для кэширования статического контента рекомендуется использовать храни-
лище объектов — такое, как Amazon S3, или специальное локальное хранилище,
которое может расти независимо от объема памяти и мощности компьютеров.
Кроме того, независимое масштабирование пространства хранения с помощью
популярных сервисов хранения объектов снижает затраты. Такие решения
могут хранить статические страницы HTML, чтобы снизить нагрузку на
веб-серверы и улучшить взаимодействие с пользователем за счет сокращения
задержки.
Управление сессиями для масштабирования
серверов приложений
Архитектурный уровень приложения получает пользовательские запросы с веб-
уровня и выполняет большую работу по вычислению бизнес-логики и взаи-
модействию с базой данных. При возрастании количества пользовательских
запросов уровень приложения должен масштабироваться, чтобы обработать
их без задержек, а затем снова сократиться при снижении нагрузки. В таких
сценариях пользователи привязываются к сессии, в которой они, например,
могут просматривать информацию с мобильного устройства и покупать товары
с десктопного компьютера. Выполнение горизонтального масштабирования
без поддержки сессий пользователей может ухудшить взаимодействие с поль-
зователем, так как предыдущие действия пользователя в процессе покупки
сохраняться не будут.
Прежде всего следует отделить пользовательские сессии от экземпляра сервера
приложения. Это означает, что сессии должны поддерживаться на независимом
уровне — скажем, в базе данных NoSQL, в которой будут храниться частично
структурированные данные.
Базы данных NoSQL лучше всего подходят для частично структурированных
данных с изменяющейся схемой. Например, один пользователь может
I аЙа J ввести свое имя и адрес при создании пользовательского профиля. Другой
пользователь может ввести дополнительные атрибуты: номер телефона, пол,
семейное положение, имя и адрес. Хотя набор атрибутов пользователей
будет отличаться, базы данных NoSQL справятся с хранением информации
и обеспечат быстрый поиск.
72 Глава 2. Принципы проектирования архитектур решений
Базы данных NoSQL — такие, как Amazon DynamoDB или MongoDB — предо-
ставляют исключительные возможности секционирования, обеспечивая легкое
горизонтальное масштабирование более высокого уровня, чем другие виды баз
данных.
Когда вы начнете хранить пользовательские сессии в базах данных NoSQL,
ваш экземпляр сможет масштабироваться горизонтально без ущерба для взаи-
модействия с пользователем. Вы можете добавить балансировщик нагрузки
перед парком серверов приложений, и он будет распределять нагрузку между
экземплярами. С помощью автомасштабирования можно автоматизировать
добавление или удаление экземпляров по требованию.
Масштабирование баз данных
Многие приложения используют реляционные БД для хранения данных транз-
акций. Технология реляционных БД существует уже несколько десятилетий
и обеспечивает надежную целостность транзакций, необходимую для многих
приложений. Тем не менее главный недостаток таких баз заключается в том, что
они не могут масштабироваться по горизонтали, если не предусмотреть другие
методы (например, шардирование) и не внести соответствующие изменения
в приложение. Это потребует значительных усилий.
Более разумным подходом будет превентивно сократить нагрузку на базы
данных. Сочетание разных методов хранения — таких, как хранение пользо-
вательских сессий в отдельных базах данных NoSQL, хранение статического
контента в хранилище объектов и использование внешнего кэша — позволяет
снизить нагрузку на основную базу данных. Лучше зарезервировать узел главной
базы данных для записи и обновления данных и использовать дополнительную
реплику для всех запросов на чтение. Например, Amazon RDS для MySQL
предоставляет для реляционных баз данных до 15 реплик для чтения.
Реплики для чтения могут создавать миллисекундные задержки при синхро-
низации с ведущим узлом, и следует учесть этот факт при проектировании
приложения. Также рекомендуется использовать механизм кэширования (на-
пример, Memcached или Redis) для сохранения частых запросов и, как следствие,
сокращения нагрузки на ведущий узел.
Если емкость базы данных начнет выходить за текущие границы, придется пере-
проектировать БД и разделить на шарды, применяя методы секционирования.
Каждый шард может расти независимо, а приложение должно определить
ключ для сохранения пользовательских данных в соответствующем шарде.
Например, если ключом раздела является имя пользователя (user_name), то
пользователи с именами от А до Е могут храниться в одном шарде, пользователи
с именами от F до I — в другом и т. д. Приложение должно направлять записи
пользователей в соответствующий раздел в зависимости от первой буквы имени.
Как видите, масштабируемость является важным фактором при проектировании
архитектуры приложения и при неправильном планировании может оказать
Построение масштабируемых архитектур 73
значительное влияние на общий бюджет проекта и взаимодействие с пользова-
телем. Архитектор решений всегда должен учитывать фактор эластичности при
проектировании приложений и оптимизации рабочих нагрузок, чтобы достичь
оптимальной производительности и минимизировать затраты.
Архитектор решений должен оценить разные варианты (например, CDN) для
масштабирования статического контента и распределения нагрузки, варианты
автомасштабирования для масштабирования серверов и различные варианты
хранения данных для кэширования, хранилищ объектов, хранилищ NoSQL,
реплик для чтения и шардирования.
Построение эластичной архитектуры
При обеспечении масштабируемости для улучшения производительности
приложения важно сохранять экономическую эффективность архитектурных
решений. Отсюда следует, что при расширении инфраструктуры сервера для
удовлетворения растущей пользовательской нагрузки система также должна
сокращаться при снижении нагрузки. Эластичность необходима для подбора
оптимального размера архитектуры, что подразумевает масштабирование ин-
фраструктуры сервера в соответствии с текущей нагрузкой. По сути, необходи-
мо обеспечить достаточную емкость для эффективной обработки аномальных
нагрузок без выделения избыточных ресурсов, которые будут простаивать при
отсутствии пиков.
Продолжим наш пример с сайтом интернет-магазина. Возьмем современную
трехуровневую архитектуру и посмотрим, как достичь эластичности на другом
уровне приложения. Мы будем обращать внимание только на вопросы эластич-
ности и масштабируемости. На рис. 2.4 представлена трехуровневая архитек-
турная диаграмма облачного технологического стека AWS.
На диаграмме изображена трехуровневая архитектура, обладающая эластич-
ностью и высокой доступностью, с упором на построение эластичного парка
серверов для эффективного управления переменными нагрузками.
Основные компоненты этой архитектуры:
• Эластичный балансировщик нагрузки автоматически распределяет входящий
трафик приложения по нескольким целям — например, экземплярам Amazon
Elastic Compute Cloud (EC2), контейнерам, IP-адресам и т. д. — в нескольких
зонах доступности. Таким образом повышается отказоустойчивость прило-
жения интернет-магазина.
• Веб-уровень состоит из группы Auto Scaling экземпляров ЕС2, спроекти-
рованных для обслуживания динамического контента приложения. Этот
парк серверов может автоматически добавлять или удалять экземпляры на
основании определенных критериев (например, загрузки процессора); это
гарантирует, что парк сможет адаптироваться к входящему трафику и под-
держивать стабильную производительность.
74 Глава 2. Принципы проектирования архитектур решений
• Уровень приложения также содержит группу Auto Scaling экземпляров ЕС2,
отвечающих за выполнение бизнес-логики приложений. Как и веб-уровень,
он может динамически регулировать свой размер под потребности рабочей
нагрузки приложения.
• Уровень базы данных содержит экземпляры Amazon RD S ( Relational Database
System), представляющие собой управляемые реляционные базы данных.
Конфигурация включает первичный экземпляр БД и реплику для чтения,
которая используется для операций с интенсивным чтением, улучшая про-
изводительность и сокращая нагрузку на первичный экземпляр. Также су-
ществует резервный экземпляр в другой зоне доступности, он обеспечивает
высокую доступность и поддержку восстановления при сбоях.
Эта архитектура формирует гибкую, масштабируемую среду приложения,
которая способна справиться с переменными рабочими нагрузками и облада-
ет высокой доступностью в нескольких зонах. Она способна автоматически
расширяться и сокращаться в соответствии с потребностями приложения,
обеспечивая стабильную и отзывчивую производительность взаимодействий
с пользователями.
Когда пользователи обращаются к приложению и взаимодействуют с ним, ис-
пользуя веб-сайт или мобильное приложение, их запросы маршрутизируются
через Amazon Route 53 — веб-сервис DNS (Domain Name System), обладающий
высокой доступностью и масштабированием. Amazon CloudFront (CDN) ис-
пользуется для эффективного распространения статического контента: графики,
таблиц стилей и файлов JavaScript. Таким образом сокращается нагрузка на
веб-серверы, а взаимодействие с пользователем улучшается за счет снижения
задержки.
Рис. 2.4. Масштабирование трехуровневой архитектуры
Построение устойчивой архитектуры с высокой доступностью 75
В этом разделе были представлены различные методы масштабирования и воз-
можности внедрения эластичности на разных уровнях архитектуры. Масштаби-
руемость является важным условием, которое обеспечивает высокую доступность
приложения и делает его устойчивым. Высокая доступность и устойчивость
более подробно рассматриваются в следующем разделе.
Построение устойчивой архитектуры
с высокой доступностью
Создание устойчивой архитектуры с высокой доступностью подразумевает про-
ектирование систем, которые могут обработать отказы отдельных компонентов
без нарушения функциональности системы в целом.
Архитектура с высокой доступностью
Любая организация стремится избежать простоев. Простои приложения при-
водят к утрате доверия со стороны бизнеса и пользователей, поэтому высокая
доступность (high availability, НА) становится одним из важнейших факторов
при проектировании архитектуры решения. Главный принцип высокой доступ-
ности звучит так: «Проектируй с учетом отказов, и отказов не будет».
Требования ко времени безотказной работы зависят от конкретного приложения.
Если приложение предназначено для большой базы внешних пользователей (на-
пример, сайт интернет-магазина или социальная сеть), необходимо обеспечить
100%-ную работоспособность. В случае внутреннего приложения (к которому
обращаются работники компании — например, система учета персонала или
интрасеть компании) могут быть приемлемы непродолжительные простои. Вы-
сокая доступность напрямую связана с затратами, поэтому архитектор решений
всегда должен планировать ее с учетом других требований.
При создании архитектуры с высокой доступностью лучше выделить для рабо-
чих нагрузок изолированный физический участок, чтобы при возникновении
сбоя в одном месте реплика приложения могла бы работать из другого места.
Архитектура с высокой доступностью непосредственно связана с самовосста-
новлением, когда вы стремитесь обеспечить стабильную работу приложения, но
тем не менее необходим механизм быстрого восстановления после сбоя, чтобы
поддержать желаемое качество пользовательского опыта.
Устойчивая архитектура
Устойчивая (resilient) архитектура означает, что приложение должно оста-
ваться доступным для пользователей во время восстановления после сбоя.
Устойчивость включает применение лучших практик для восстановления при-
ложения после повышенных нагрузок, обусловленных увеличением количества
76 Глава 2. Принципы проектирования архитектур решений
пользовательских запросов, злонамеренных атак и отказов компонентов архитек-
туры. Она должна существовать на всех уровнях архитектуры, включая уровни
инфраструктуры, приложения, баз данных, безопасности и сетей. Устойчивая
архитектура должна восстанавливаться после сбоев за желаемое время.
Чтобы сделать архитектуру устойчивой, необходимо определить время восста-
новления и решить следующие задачи:
• определить и реализовать избыточные архитектурные компоненты там, где
это требуется;
• понять, когда следует исправлять архитектурные компоненты, а когда их
лучше заменять. Например, исправление проблемы с сервером может занять
больше времени, чем его замена образом той же машины.
Достижение избыточности
Избыточность — критически важное условие построения устойчивых систем.
Создание устойчивой архитектуры требует многоуровневой стратегии избыточ-
ности. Эта стратегия включает развертывание серверных кластеров на разных
стойках в одном дата-центре, расширение на несколько дата-центров в одном
регионе и далее по разным географическим регионам. Географическое распреде-
ление обеспечивает защиту от локальных и региональных стихийных бедствий
и сокращает задержку для глобальной пользовательской базы.
Внедрение интеллектуального распределения нагрузки и глобального управле-
ния трафиком (например, маршрутизации на базе DNS с проверкой работоспо-
собности) гарантирует, что пользователи всегда будут обслуживаться из наиболее
подходящей локации. Устойчивость баз данных достигается стратегической
репликацией, с автоматизированными механизмами отработки отказов для
поддержания доступности и целостности баз данных.
Если серверы распределены по разным физическим локациям, первый уровень
маршрутизации трафика может обеспечиваться сервером DNS еще до того, как
трафик достигнет балансировщика нагрузки. Таким образом в случае сбоя во
всем регионе приложение будет работать.
Как видно из приведенного выше рисунка, устойчивость должна обеспечи-
ваться на всех критических уровнях, влияющих на доступность архитекту-
ры; это позволит реализовать решение, способное пережить сбои. Помимо
использования сервера DNS для маршрутизации трафика между разными
физическими локациями, необходимо применять следующие лучшие практики,
чтобы сформировать избыточную среду и обеспечить устойчивость:
• использовать CDN для распределения и кэширования статического контента
(видео, графики, статических веб-страниц) поблизости от местонахождения
пользователя, чтобы приложение всегда оставалось доступным;
Построение устойчивой архитектуры с высокой доступностью
77
Автомасшта-
бирование
ф
-»О
ф
Парк
серверов
Парк
серверов
Главная
база данных
Резервная
база данных
м
S
Рис. 2.5. Обеспечение устойчивости архитектуры приложений
с использованием сервера DNS
• по достижении трафиком границ региона применять балансировщик нагрузки
для маршрутизации трафика по парку серверов, чтобы приложение работало
даже в том случае, если один узел в регионе потеряет работоспособность;
• использовать автомасштабирование для добавления или удаления серверов
в зависимости от потребности пользователя. Так приложение не будет за-
висеть от сбоев отдельных серверов;
• создавать резервную базу данных, чтобы приложение оставалось доступным
в случае сбоя основной БД.
Обработка отказов компонентов
На случай отказа какого-либо компонента должна существовать его резервная
копия для восстановления и достижения устойчивости архитектуры. Балан-
сировщик нагрузки и маршрутизаторы на сервере DNS выполняют проверку
работоспособности, чтобы убедиться, что трафик направляется только к работо-
способным экземплярам приложения. Эту схему можно настроить для поверх-
ностной проверки работоспособности, при которой отслеживаются локальные
сбои хостов, или глубокой проверки, при которой также могут решаться про-
блемы со сбоями зависимостей. Однако глубокая проверка работоспособности
78 Глава 2. Принципы проектирования архитектур решений
занимает больше времени и требует больших ресурсов, чем поверхностная. Вы
узнаете больше об устойчивых архитектурах в главе 8 «Факторы надежности
архитектуры».
На уровне приложений важно избегать каскадных отказов, при которых отказ
одного компонента может вывести из строя всю систему. Для снижения риска
каскадных отказов в системе могут применяться различные механизмы.
• Тайм-ауты: назначение максимального времени для операций и запросов
может предотвратить бесконечное ожидание ответа, приводящее к истоще-
нию ресурсов.
• Отклонение трафика: перегруженная система может активно отклонять
новые запросы, чтобы предотвратить перегрузку и обеспечить стабильность
существующих процессов.
• Идемпотентные операции: обеспечение повторяемости операций без не-
желательных эффектов может способствовать восстановлению после про-
межуточных отказов без дублирования действий или появления несогласо-
ванности состояний.
• Прерыватели: реализация паттерна «Прерыватель» (circuit breaker) позво-
ляет обнаруживать признаки отказов и блокировать дальнейшие запросы
к проблемному сервису, позволяя ему восстановиться и предотвращая рас-
пространение отказов на другие части системы.
Внедрение таких стратегий делает системы более устойчивыми, сохраняет функ-
циональность при отказе отдельных компонентов и не позволяет этим отказам
превратиться в масштабный сбой системы.
Высокая доступность и устойчивость поддерживают работоспособность системы
и ее доступность для пользователей. Однако необходимо поддерживать произ-
водительность на должном уровне также и в случае отказов. Обратимся теперь
к теме отказоустойчивости (fault-tolerance).
Отказоустойчивые архитектуры
Высокая доступность означает, что приложение остается доступным для
пользователя, но при этом работать с пониженной производительностью.
Представим, что для обработки пользовательского трафика необходимы че-
тыре сервера. Вы размещаете по два сервера в двух физически изолированных
дата-центрах. Если в одном центре происходит сбой, пользовательский трафик
будет обслуживаться другим. Но теперь в вашем распоряжении только два
сервера, а это означает, что доступно только 50 % исходной емкости и поль-
зователи могут столкнуться с проблемами производительности. В таком
сценарии приложение обладает 100 %-ной высокой доступностью, но только
50 %-ной отказоустойчивостью.
Отказоустойчивые архитектуры 79
Как видно из рис. 2.6, для достижения 100 %-ной отказоустойчивости необхо-
димо обеспечить полную избыточность и поддерживать удвоенное количество
серверов, чтобы пользователь не сталкивался с проблемами производительности
при сбое в одной из зон.
Отказоустойчивость подразумевает успешную обработку рабочей нагрузки при
возникновении сбоев без ущерба для производительности системы. Полностью
отказоустойчивая архитектура подразумевает высокие затраты, связанные
с повышенной избыточностью. Вопрос, сможет ли ваша пользовательская база
смириться со снижением производительности на период восстановления, за-
висит от критичности приложения.
При проектировании архитектуры приложения архитектор решения должен
определить особенности пользователей приложения и ответить на вопрос,
обязательна ли 100 %-ная отказоустойчивость (которая неизбежно отразится на
затратах). Например, веб-сайту интернет-магазина 100 %-ная отказоустойчивость
может быть необходима, поскольку снижение производительности напрямую
влияет на выручку. В то же время внутренняя система расчета заработной
платы, где сотрудники проверяют свои зарплатные ведомости в конце месяца,
может на непродолжительное время выдержать снижение производительности.
В следующем разделе более подробно рассматривается тема построения высоко-
производительных архитектур.
100 %-ная высокая доступность, 50 %-ная отказоустойчивость
100 %-ная высокая доступность, 100 %-ная отказоустойчивость
Рис. 2.6. Отказоустойчивая архитектура
80 Глава 2. Принципы проектирования архитектур решений
Проектирование с учетом
производительности
С появлением доступного быстрого интернета заказчики стали требовать
высокопроизводительных приложений с минимальным временем загрузки.
Организации заметили, что их доходы прямо пропорциональны производитель-
ности приложения и замедление его загрузки может значительно повлиять на
активность потребителей.
Современные компании имеют высокие ожидания в отношении производитель-
ности. Высокопроизводительные приложения стали необходимым условием
для выживания на рынке.
Производительность, как и устойчивость, должна учитываться архитектором
решений на каждом уровне проектирования. Команда DevOps должна наладить
мониторинг и отслеживать, что эффективность приложения поддерживается на
должном уровне, а также работать над его постоянным усовершенствованием.
Повышение производительности означает усиление клиентской активности
и, как следствие, более высокую рентабельность.
Высокопроизводительные приложения решают проблему замедления работы,
которое может быть вызвано внешними факторами, такими как медленное под-
ключение к интернету. Например, можно спроектировать веб-страницу блога
так, чтобы при доступности быстрого интернета она загружалась за 500 милли-
секунд. Но при медленном подключении можно начать с загрузки текста, чтобы
пользователь мог читать его, пока загружаются графика и видео.
В идеальной среде с ростом рабочей нагрузки механизмы автоматизированного
масштабирования начинают обрабатывать дополнительные запросы, никак не
влияя на производительность приложения. Но в реальности задержка приложе-
ния кратковременно вырастает, пока осуществляется масштабирование. Чтобы
понять, как приложение поведет себя в реальной ситуации, лучше протестировать
его на производительность — повысить нагрузку и проверить, удастся ли достичь
желаемого параллелизма и качества пользовательского опыта.
На уровне серверов необходимо выбрать подходящий сервер в зависимости от
рабочей нагрузки. Например, проведите тестирование для определения нуж-
ного объема памяти, поскольку переполнение памяти может замедлить работу
приложения и даже с течением времени привести к сбою на сервере. Выберите
подходящее значение IOPS (Input/output Operations Per Second, количество
операций ввода/вывода в секунду) для хранилища. Высокое значение IOPS
необходимо для приложений с интенсивной записью для сокращения задержки
и повышения скорости записи на диск.
Чтобы обеспечить более высокую производительность, применяйте кэширова-
ние на каждом уровне архитектуры. Оно обеспечивает локальную доступность
данных для пользователей или хранение их в памяти для выдачи сверхбыстрого
ответа.
Создание неизменяемой архитектуры
81
IOPS - метрика производительности, используемая для определения скорости,
/УуА с которой устройства хранения (жесткие диски, SSD, сети хранения данных)
I /йч J могут читать и записывать данные. Каждая операция ввода или вывода может
х7 быть операцией чтения или записи данных.
При добавлении кэширования на разных уровнях архитектуры приложения
необходимо учитывать следующее:
• для загрузки часто запрашиваемых веб-страниц используйте кэш браузера
в системе пользователя;
• для быстрого поиска веб-сайтов — кэш DNS;
• для графики высокого разрешения и видеороликов, хранящихся поблизости
от местоположения пользователя, — кэш CDN;
• для обслуживания частых запросов из памяти — кэш базы данных;
• на уровне серверов используйте максимальный объем кэша в памяти для
обслуживания пользовательских запросов;
• для обслуживания частых запросов из системы кэширования применяйте
такие механизмы кэширования, как Redis и Memcached;
• предусмотрите ситуацию устаревания кэша — это процесс, в результате
которого данные кэша становятся неактуальными и помечаются на обнов-
ление или удаление. Вытеснение данных из кэша — процесс, в результате
которого данные удаляются из кэша, обычно чтобы освободить место для
новых данных.
Как видите, забота о производительности приложения — важная задача про-
ектирования, напрямую связанная с прибыльностью организации. Архитектор
решений должен думать о производительности при планировании решения и по-
стоянно работать над ее повышением. В главе 6 «Факторы производительности»
мы глубже рассмотрим эту тему и изучим способы оптимизации приложения
для улучшения производительности.
Создание неизменяемой
архитектуры
Организации инвестируют в оборудование и внедряют практику регулярного
обновления серверного программного обеспечения на новые версии и конфи-
гурации. Со временем это может привести к тому, что разные серверы будут
работать в разных конфигурациях, а это усложняет диагностику проблем. Иногда
организациям приходится поддерживать работу лишних ресурсов, без которых
можно было бы обойтись, потому что непонятно, какой сервер можно безболез-
ненно отключить и это не приведет к сбою приложения. Трудности с заменой
серверов также усложняют развертывание и тестирование любых обновлений
парка серверов. Эти проблемы можно решить, рассматривая сервер как замеща-
емый (replaceable) ресурс. Из-за этого при проектировании приложения всегда
82 Глава 2. Принципы проектирования архитектур решений
следует продумывать неизменяемость (immutability) инфраструктуры. Это
означает, что в ходе обновления приложений потребуется заменять не только
программную, но и аппаратную часть.
Организация работы с серверами по принципу cattle, not pets1 имеет фундамен-
тальное значение в современных облачных архитектурах. Такой подход означает,
что тщательное обслуживание и настройка отдельных серверов не предусмотре-
ны, пока они не станут незаменимыми. Вместо этого серверы проектируются
для быстрого добавления, единообразного управления и удаления или замены
без значительных последствий для системы в целом. Эта методология улучшает
масштабируемость и устойчивость, поскольку позволяет быстро адаптироваться
к колебаниям нагрузки или восстанавливаться после отказов.
Чтобы создать заменяемые серверы, проектируйте приложения без сохранения
состояния и избегайте жесткого кодирования IP-адресов серверов или имен DNS
баз данных — это поможет избежать отказов в процессе замены. Рассматривайте
инфраструктуру как код, а не как оборудование и не применяйте обновления
к работающей системе.
Созданию неизменяемой инфраструктуры способствует распространение вирту-
альных машин. Вы можете создать эталонный образ своей виртуальной машины
и развертывать его с новой версией инфраструктуры вместо того, чтобы обнов-
лять существующую версию. Всегда создавайте новые экземпляры серверов на
базе эталона, который служит шаблоном и содержит все необходимые средства
безопасности и программные компоненты. Такая стратегия развертывания также
упрощает диагностику серверов: вы можете избавиться от проблемного сервера
и создать новый сервер по эталонному образу.
Всегда сохраняйте резервную копию журнала для анализа первопричин, прежде
чем избавляться от проблемного сервера. Такой подход также обеспечивает со-
гласованность между средами, так как один базовый образ сервера используется
для создания всех рабочих сред.
Слабая связанность — еще один критический принцип дизайна, дополняющий
подход cattle, not pets. В этой парадигме компоненты системы проектируются
так, чтобы взаимодействовать друг с другом через четко определенные интер-
фейсы и быть достаточно независимыми, чтобы изменения в одном компоненте
не требовали изменения других компонентов.
Такое разделение улучшает гибкость и масштабируемость, позволяя отдельным
компонентам развиваться, масштабироваться или восстанавливаться после от-
казов независимо от других. Рассмотрим концепцию слабой связанности более
подробно.
1 Cattle, not pets (англ.) — буквально «скот, а не домашние питомцы». Принцип, согласно
которому серверы создаются так, чтобы в дальнейшем требовать минимального участия
человека (по аналогии с уходом за скотом в противоположность уходу за домашними
питомцами, требующими большего внимания и участия). — Примеч.ред.
Слабая связанность 83
Слабая связанность
Традиционные приложения развертывались в парке серверов с жесткой ин-
теграцией, где каждый сервер имел конкретную обязанность. Часто прило-
жение зависит от нескольких серверов, обеспечивающих полноту его функ-
циональности.
Как показано на диаграмме
(рис. 2.7), в сильно связанной
архитектуре парк веб-серверов
напрямую зависит от всех сер-
веров приложений, и наоборот.
На этой архитектурной диаграм-
ме в случае выхода из строя од-
ного сервера приложения все
веб-серверы начнут получать
ошибки, так как запрос будет на-
правляться неработоспособному
серверу приложения. А это может
Парк веб-серверов
привести к отказу всей системы. Парк серверов приложений
В сильносвязанной архитектуре рис. 2.7. Сильносвязанная архитектура
масштабирование путем добав-
ления и удаления серверов потребует значительных усилий, поскольку нужно
правильным образом настроить все связи.
При слабой связанности можно
добавить промежуточный уро-
вень (например, балансировщик
нагрузки или очередь), который
автоматически обработает отка-
зы или произведет масштабиро-
вание за вас.
На следующей архитектурной
диаграмме (рис. 2.8) между пар-
ками веб-серверов и серверов
приложений установлен балан-
сировщик нагрузки, который
следит за тем, чтобы запросы
пользователей всегда обслужи-
вались работоспособным серве-
ром приложения.
Если один из серверов приложе-
ний выйдет из строя, баланси-
ровщик нагрузки автоматически
Парк веб-серверов
Парк серверов приложений
Рис. 2.8. Слабосвязанная архитектура
на базе балансировщика нагрузки
84 Глава 2. Принципы проектирования архитектур решений
начинает перенаправлять весь трафик трем другим работоспособным серверам.
Слабосвязанная архитектура также помогает независимо масштабировать
серверы и корректно заменять неработоспособные экземпляры. Она повышает
отказоустойчивость приложения, так как радиус ошибки ограничивается всего
одним экземпляром.
Слабосвязанные архитектуры также могут создаваться на базе очереди; для при-
мера возьмем веб-сайт обработки графики, на котором пользователь сохраняет
изображение, а затем обрабатывает его для кодирования, генерирования мини-
атюр и добавления информации об авторском праве (рис. 2.9). На следующей
архитектурной диаграмме показано разделение связей на базе очереди. В этой
ситуации слабая связанность систем достигается благодаря использованию
очередей между системами и обмену сообщениями, которые передают задания.
Разделение связей на базе очереди делает возможным асинхронное связывание
систем, при котором один сервер не ожидает ответа от другого сервера, а работает
независимо. Этот метод позволяет увеличить количество виртуальных серверов,
которые получают и обрабатывают сообщения параллельно. Вы можете настро-
ить автомасштабирование, чтобы завершить работу лишних серверов, — напри-
мер, если изображений для обработки больше не останется.
В сложной системе слабая связанность реализуется с помощью микросервис-
ной архитектуры, при которой независимые сервисы содержат полный набор
функциональности и взаимодействуют друг с другом по стандартному про-
токолу. В современном проектировании подобные событийно-управляемые
архитектуры стали чрезвычайно популярными, так как они упрощают ослабле-
ние связей между компонентами приложения. Слабосвязанные архитектуры
имеют множество преимуществ, от масштабируемости и высокой доступности
до простоты интеграции.
Сервисы,а не серверы 85
Сервисы, а не серверы
В предыдущем разделе вы узнали, что такое слабая связанность и почему для
обеспечения масштабируемости и отказоустойчивости так важно, чтобы архи-
тектуры были слабосвязанными. Сервис-ориентированный подход помогает до-
биться слабосвязанной архитектуры (в отличие от серверно-ориентированного,
который может привести к зависимости от оборудования и сильно связанной
архитектуре). Событийно-управляемая архитектура на базе микросервисов
облегчает развертывание и обслуживание решения.
В RESTful-архитектуре сообщение можно форматировать в XML, JSON или
в простом тексте и отправлять его по интернету с использованием простого
протокола HTTP. RESTful-архитектура популярна прежде всего благодаря
своей максимальной легковесности. Микросервисы основаны на RESTful-
архитектуре и могут масштабироваться независимо, что упрощает расширение
или сокращение отдельного компонента приложения без последствий для
других.
Как видно из следующей диаграммы (рис. 2.10), в монолитной архитектуре все
компоненты встраиваются в один сервис, вследствие чего развертываются на
одном сервере и привязываются к одной базе данных. Это создает жесткую за-
висимость. С другой стороны, в микросервисной архитектуре каждый компонент
существует независимо от других и использует свою базу данных, что позволяет
ему масштабироваться независимо.
Монолитная архитектура
Контент на сервере
Заказ
Наличие
товара
Корзина
Оценки и отзывы
База данных
Микросервисная архитектура
Рис. 2.10. Монолитная и микросервисная архитектуры
86 Глава 2. Принципы проектирования архитектур решений
На этой диаграмме изображен пример веб-сайта интернет-магазина с моно-
литной и микросервисной архитектурой. На сайте клиенты могут ввести свои
регистрационные данные и разместить заказ (при условии, что нужные им
товары имеются в наличии), добавив товары в корзину.
Чтобы преобразовать монолитную архитектуру в микросервисную, можно
создать приложения из небольших независимых компонентов, которые обра-
зуют отдельные части.
Метод модуляризации снижает затраты, размеры и риск изменений. В рассмо-
тренном случае каждый компонент создается как сервис. Сервис входа может
масштабироваться независимо для обработки возросшего трафика, так как
клиенты могут часто входить в приложение для изучения каталога продуктов
и статуса заказа. Со своей стороны, сервисы заказа и корзины могут получать
меньше трафика, так как клиент размещает заказы не так часто.
При проектировании решения архитектор должен помнить о микросервисах.
Очевидное их преимущество заключается в снижении общего объема кода,
который необходимо поддерживать, и в автономности.
С другой стороны, мониторинг микросервисов требует более гранулярного
подхода по сравнению с традиционными монолитными приложениями из-за
распределенной природы микросервисов. Каждый микросервис функционирует
независимо, а это означает, что мониторинг должен быть реализован как на уров-
не отдельных сервисов, так и на общесистемном уровне, чтобы иметь целостное
представление о корректной работе и производительности приложения.
Микросервисы можно строить без внешних зависимостей. Все предварительные
условия включаются в сервис, что обеспечивает слабую связанность и масшта-
бируемость, а также сокращает зону поражения в случае отказа.
В любой архитектуре приложения центральное место занимают данные. Если
вы начнете работать от данных, это позволит построить более эффективную
архитектуру. В следующем разделе более подробно рассматривается проекти-
рование на основе данных.
Проектирование на основе данных
В любом программном решении центральное место занимают сбор и управ-
ление данными. Для примера еще раз возьмем веб-сайт интернет-магазина;
приложение представляет данные товаров на сайте и стимулирует пользо-
вателей к покупкам. Работа приложения начинается с получения данных
пользователя при входе, затем приложение добавляет метод платежа, со-
храняет информацию о заказах и ведет учет складских данных по мере про-
даж. Другой пример — банковское приложение, которое хранит финансовую
информацию пользователей и управляет всеми данными финансовых опера-
ций с обеспечением целостности и согласованности. Самое важное в любом
приложении — правильная обработка, хранение и защита данных. Данные
Забота о безопасности на всех уровнях 87
влияют на проектирование решения, и на их основе можно создать решение,
соответствующее заданным требованиям.
Данные занимают центральное место не только в проектировании приложения,
но и в его эксплуатации и обслуживании, а также в бизнес-решениях. Необходимо
добавлять средства мониторинга, которые будут обеспечивать беспроблемную
работу приложения и бизнеса. Например, для мониторинга приложения необ-
ходимо получать данные журналов с сервера и создать дашборд для наглядного
представления метрик. Непрерывный мониторинг данных и отправка оповеще-
ний при возникновении проблем помогут быстро восстановиться после отказа
за счет механизма автовосстановления.
Как архитектор решений вы должны продумать дизайн приложения и общий
план реализации бизнес-возможностей, включая способы сбора данных и их ис-
пользования в приложении. Данные — ваше богатство, и сбор аналитики данных
может значительно повысить прибыльность организации.
Забота о безопасности на всех уровнях
Безопасность — один из важнейших вопросов проектирования приложений.
Любой пробел в системе безопасности может иметь катастрофические по-
следствия для бизнеса или будущего организации. Многие компании страдали
от взлома, что приводило к потере доверия клиентов и вредило репутации.
Соблюдение таких отраслевых норм, как PCI (Payment Card Industry), HIPAA
(Health Insurance Portability and Accountability Act), GDPR (General Data
Protection Regulation) и SOC (System and Organization Controls), играет
ключевую роль для защиты данных в разных областях. PCI защищает ин-
формацию кредитных карт в финансовой сфере, HIPAA защищает данные
пациентов в здравоохранении, GDPR повышает конфиденциальность данных
в Евросоюзе, a SOC обеспечивает безопасность управления данными в об-
служивающих организациях, устанавливая меры безопасности для защиты
клиентских данных и предоставляя организациям рекомендации по соблю-
дению стандартов. В зависимости от отрасли и региона также необходимо
соблюдать местное законодательство.
Безопасность может значительно влиять на дизайн решения, так что понять по-
требности в безопасности необходимо еще до начала проектирования. Безопас-
ность должна быть внедрена в платформу на аппаратном уровне и в разработку
приложения на программном уровне.
Ниже перечислены ключевые соображения, которые необходимо учесть на
этапе проектирования.
• Физическая безопасность дата-центра: все ИТ-ресурсы в дата-центрах
должны быть защищены от несанкционированного доступа.
• Сетевая безопасность: сеть должна быть защищена для предотвращения
любых попыток несанкционированного доступа к серверам.
88 Глава 2. Принципы проектирования архитектур решений
• Управление доступом и идентификационными данными (IAM, Identity and
Access Management): только пользователи, прошедшие аутентификацию,
должны иметь доступ к приложению, при этом им разрешается выполнение
операций, соответствующих их уровню авторизации.
• Безопасность данных при передаче: данные должны быть защищены при
передаче по сети или интернету.
• Безопасность данных при хранении: данные должны быть защищены при
хранении в базе данных или другом хранилище.
• Мониторинг безопасности: любые инциденты безопасности должны быть
обнаружены, а команда поставлена в известность для дальнейших действий.
При проектировании приложения необходимо соблюдать баланс требований
безопасности (например, шифрования) и других факторов (таких, как произ-
водительность и задержка). Шифрование данных всегда влияет на произво-
дительность, поскольку добавляет уровень обработки — данные необходимо
дешифровать для использования. Затраты на дополнительную обработку шиф-
рования не должны влиять на общую производительность приложения, поэтому
при проектировании приложения следует продумать сценарии использования,
в которых требуется шифрование. Например, если приложение работает с кон-
фиденциальными данными, их необходимо зашифровать.
Другой аспект, относящийся к безопасности, который необходимо учитывать
при проектировании приложений, — комплаенс, соответствие локальному зако-
нодательству. Это особенно важно, если приложение относится к регулируемой
отрасли: здравоохранению, финансам или федеральной власти. У каждого вида
комплаенса есть свои требования, в которые обычно входит защита данных
и регистрация всех операций для целей аудита. Дизайн приложения должен
включать систему ведения журналов и мониторинга, которая будет удовлетво-
рять требованиям аудита.
Безопасность — одно из самых важных условий устойчивости приложений.
С точки зрения безопасности DDoS-атака (Distributed Denial of Service, то есть
«распределенный отказ в обслуживании») потенциально может повлиять на до-
ступность сервисов и приложений. DDoS-атаки обычно генерируют фиктивный
трафик к серверу и перегружают его, в результате чего легитимные пользователи
не могут обратиться к приложению. Это может происходить на сетевом уровне
или на уровне приложения. Важно принять упреждающие меры для предот-
вращения DDoS-атак. Старайтесь располагать как можно более значительную
часть рабочей нагрузки приложения в частной сети и не предоставлять доступ
к конечным точкам приложения из интернета, если это возможно.
Автоматизация безопасности — еще один фактор, который необходимо после-
довательно реализовать при проектировании, чтобы сократить риск наруше-
ний безопасности. Автоматизация в безопасности подразумевает применение
Удобство использования и доступность приложений 89
технологии для выполнения задач безопасности без вмешательства человека,
оптимизацию обнаружения, анализа и исправления инцидентов безопасности.
Интегрируя автоматизированные средства безопасности, можно обеспечить не-
прерывный мониторинг и обнаружение угроз в реальном времени, что ускорит
реагирование на попытки взлома и уязвимости.
В этом разделе вы узнали, как применять принципы безопасности при
проектировании и учитывать нормативные требования. Впрочем, это лишь
общий обзор. Более подробно тема рассматривается в главе 7 «Факторы
безопасности».
Даже продукт с широкой функциональностью может не понравиться пользова-
телям, если с ним будет неудобно работать. Удобство использования и доступ-
ность приложения чрезвычайно важны для успеха продукта. Об этом вы больше
узнаете в следующем разделе.
Удобство использования и доступность
приложений
Важными параметрами дизайна также являются удобство использования (юза-
билити) и доступность приложения, которые оказывают значительное влияние
на опыт пользователя. Юзабилити определяет, насколько просто и интуитивно
взаимодействие с приложением; в частности, это подразумевает понятный ин-
терфейс, логичную навигацию и эффективные процессы выполнения действий.
Доступность означает, что с приложением смогут работать люди с ограничен-
ными возможностями. Рассмотрим эти параметры более подробно.
Удобство использования
У пользователей не должно возникать проблем при работе с приложением. Она
должна проходить настолько гладко, чтобы пользователь даже не заметил, как
легко он находит нужную информацию.
Удобство использования, или юзабилити, определяет, насколько быстро поль-
зователь может освоить логику навигации при знакомстве с приложением.
Кроме того, важно, насколько быстро пользователь возвращается к нормальной
работе после допущенной ошибки и оптимальны ли его действия. Сложные
и полнофункциональные приложения имеют смысл только в том случае,
если с ними можно эффективно работать. Ваша цель — создать интуитивный
и удобный интерфейс, который улучшает взаимодействие с пользователем
и гарантирует, что функциональность приложения будет доступной и по-
нятной для всех.
Важную роль в проектировании с учетом удобства использования играют ис-
следования пользователей и тестирование.
90 Глава 2. Принципы проектирования архитектур решений
Доступность
Проектируемое приложение часто предназначено для глобальной аудитории или
широкого географического региона. У пользователей будут разные технические
и физические возможности. Доступность означает инклюзивность: приложение
должно быть доступно всем, включая пользователей с медленным интернетом,
владельцев устаревших устройств или людей с ограниченными возможностями.
При проектировании приложения архитектор решения обязательно должен
учитывать фактор доступности. Иногда для этого приходится создавать от-
дельную версию приложения.
Решение с высокой доступностью должно включать такие компоненты, как
распознавание голоса и голосовая навигация, экранные лупы и экранные дик-
торы — например, для слабовидящих пользователей.
Локализация помогает сделать приложение доступным на языке конкретного
региона (например, испанском, немецком, хинди или японском), чтобы гло-
бальные пользователи со всего мира могли взаимодействовать с приложением
на языке своего региона.
Как показано на рис. 2.11, юзабилити и доступность формируют удовлетворен-
ность потребителей.
Рис. 2.11. Удовлетворенность потребителей как следствие удобства
использования и доступности
Для обеспечения юзабилити и доступности необходимо знать своих пользова-
телей, причем доступность является частью удобства использования, так как
они неразрывно связаны. Прежде чем приступать к проектированию решения,
архитектор решений должен поработать с владельцем продукта и изучить поль-
зовательскую аудиторию, проводя интервью и опросы, а также собрав обратную
Построение расширяемой и future-proof архитектуры 91
связь по имитации фронтенд-интерфейса. Он должен понимать ограничения
пользователей и предоставить им необходимые вспомогательные средства.
При запуске продукта команда должна запланировать A/В-тестирование, в ходе
которого небольшая часть пользователей получает доступ к новым возможно-
стям, и ее реакции анализируются. А/В-тестирование сравнивает две версии
приложения, оценивает их производительность и определяет предпочтительный
вариант. Для улучшения дизайна в работающем приложении должен быть преду-
смотрен механизм непрерывной обратной связи (в виде формы для заполнения
или службы поддержки пользователей).
По мере развития пользовательской базы архитектура должна быть способна
справляться с ростом требований. Для этого она должна быть расширяемой
и защищенной от устаревания, адаптируемой к будущим изменениям (future-
proof). Давайте посмотрим, как обеспечить жизнеспособность архитектуры
в долгосрочной перспективе.
Построение расширяемой и future-proof
архитектуры, подходящей для повторного
использования
Компании развиваются по мере роста; приложения масштабируются с учетом
растущей пользовательской базы и дополняются новыми возможностями для
получения конкурентных преимуществ. Архитектура решения должна быть рас-
ширяемой и достаточно гибкой для изменения существующей или добавления
новой функциональности.
Чтобы добиться расширяемости решения, его архитектор должен использовать
слабосвязанные архитектуры везде, где это возможно. На высоком уровне ос-
лаблению связей между модулями или приложениями может способствовать
создание RESTful-архитектуры или архитектуры на базе очереди. О других
разновидностях архитектур вы подробнее узнаете в главе 4 «Паттерны про-
ектирования архитектур решений». В этом разделе концепция архитектурной
гибкости будет рассмотрена на простом примере.
Чтобы выделить в приложении модули, организации часто стараются построить
платформу для разных видов функциональности и запустить их в виде отдельных
приложений. Такое возможно, только если архитектура является подходящей
для повторного использования.
На рис. 2.12 изображена архитектура на базе API в приложении интернет-мага-
зина. Она включает независимые сервисы (каталога товаров, заказов, платежей,
доставки), в нужный момент используемые приложением конечного пользова-
теля. Клиент использует мобильные и браузерные приложения для размещения
заказа на сайте. Таким приложениям нужны сервис каталога товаров, чтобы
клиент мог выбрать товары на сайте, сервис заказов для оформления покупки
и сервис платежей для обработки оплаты.
92 Глава 2. Принципы проектирования архитектур решений
Рис. 2.12. Расширяемая архитектура на базе API
В свою очередь, сервис каталога товаров и сервис заказов взаимодействуют
с сервисом доставки для отправки заказанных товаров клиенту. С другой
стороны, физические магазины используют системы точек продаж, в которых
представитель клиента сканирует штрихкоды, размещает заказы по поручению
клиента и получает платежи. Сервис доставки в этом случае не нужен, так как
клиент забирает товар в магазине.
На рис. 2.12 представлен API бонусов, используемый для интеграции сторон-
них API. Такая архитектура позволяет расширить текущее решение для инте-
грации API, предназначенных для удержания клиентов, и привлечения новых
клиентов за счет предоставления различных бонусов при покупке. Как видно
из диаграммы, сервисы платежей используются при заказах как на сайте, так
и в магазине. Другой сервис может повторно использовать сервис платежей,
если организация захочет принимать платежи для сервиса подарочных карт,
сервисов доставки продуктов и т. д.
Расширяемость и возможность повторного использования не ограничиваются
уровнем проектирования сервисов — они уходят глубоко на уровень API, где
архитектор продукта должен применять концепции объектно-ориентированного
анализа и проектирования (ООАП) — такие, как наследование — для создания
фреймворка API. Фреймворк может расширяться и повторно использоваться
для добавления новой функциональности в тот же сервис.
Архитектурная интероперабельность и портируемость 93
ООАП - фундаментальный метод программной инженерии, который помогает
-СА- ) разработчикам более эффективно планировать и моделировать приложения,
7 обеспечивая модульность, масштабируемость и удобство обслуживания
продукта.
Чтобы можно было расширить функциональность приложения, оно должно
бесшовно интегрироваться с другими продуктами, в которых может работать
с более широким набором данных и операций. Обеспечение совместимости
приложения с экосистемой помогает добавлять новые возможности с исполь-
зованием смежных приложений. В следующем разделе создание совместимой
архитектуры рассматривается более подробно.
Архитектурная интероперабельность
и портируемость
Архитектурная интероперабельность и портируемость — важнейшие параме-
тры современной программной архитектуры, гарантирующие, что приложения
будут работать в разных средах и бесшовно взаимодействовать с другими
системами.
Интероперабельность приложений
Интероперабельностью называется способность одного приложения взаимо-
действовать с другими по стандартному формату или протоколу. Часто при-
ложение должно взаимодействовать с различными вышележащими системами
для потребления данных и нижележащими — для поставки данных, поэтому
важно организовать эти взаимодействия предельно гладко.
Например, приложение интернет-магазина должно работать с другими прило-
жениями в экосистеме управления цепочкой поставок. К числу таких прило-
жений относятся корпоративные приложения планирования ресурсов, а также
приложения, которые управляют жизненным циклом перевозок, хранят инфор-
мацию о транспортных компаниях, управляют заказами, складскими запасами
и персоналом.
Чтобы обеспечить сквозной путь от клиента к получению товара, все приложения
должны обмениваться данными без каких-либо проблем. Это актуально и для
приложений из многих других отраслей, будь то здравоохранение, производство
или телекоммуникации.
Архитектор решений должен учитывать интероперабельность приложений
в процессе проектирования. Для этого он выявляет зависимости между систе-
мами и работает с ними. Необходимым условием интероперабельности является
единообразное взаимодействие между системами без дополнительных усилий
по отправке данных, что обеспечивает значительную экономию.
94
Глава 2. Принципы проектирования архитектур решений
Объем отправки и получения данных в каждой отрасли свой, и его необходимо
понимать и учитывать. В общем случае при проектировании программных
систем лучше выбрать популярный формат (например, JSON или XML) для
разных приложений, чтобы они взаимодействовали друг с другом. Оба формата
поддерживаются в современных RESTful-API и микросервисных архитектурах
по умолчанию.
Портируемость приложений
Портируемость системы позволяет приложению работать в разных средах без
изменений (или с минимальными изменениями). Любое приложение должно
работать с разными операционными системами и оборудованием.
Технологии стремительно развиваются, выпускаются новые версии языков,
платформ разработки и операционных систем. Необходимо позаботиться о том,
чтобы приложение могло приспособиться к таким изменениям. Мобильные
приложения стали неотъемлемой частью любого системного решения и долж-
ны быть совместимы с основными платформами мобильных операционных
систем — таких, как iOS и Android.
На этапе проектирования архитектор решений должен выбрать технологию,
которая обеспечит требуемый уровень портируемости приложения. Например,
если вы собираетесь развернуть свое приложение в разных операционных си-
стемах, подойдет такой язык, как Java, так как он поддерживается всеми опера-
ционными системами и приложение сможет работать на другой платформе без
необходимости портирования. Для мобильных приложений архитектор может
выбрать фреймворк на базе JavaScript (такой, как React Native), который обес-
печит возможность кроссплатформенной мобильной разработки.
Интероперабельность улучшает расширяемость системы, а портируемость
увеличивает возможности использования приложения. Обе характеристики
являются критическими для дизайна приложения и могут создавать экспонен-
циальные затраты, если архитектор не позаботился о них в ходе проектирования.
Архитектор должен тщательно проработать их на уровне отраслевых требований
и системных зависимостей.
Для сокращения количества ошибок и повышения эффективности чрезвычайно
важна автоматизация. Эта тема рассматривается в следующем разделе.
Повсеместное применение автоматизации
Большинство инцидентов происходит из-за человеческих ошибок, которых мож-
но избежать благодаря автоматизации. Автоматизация не только эффективно
обрабатывает задачи, но и повышает производительность и экономит затраты.
Любая повторяемая задача может быть автоматизирована для высвобождения
ценных человеческих ресурсов, чтобы участники команды могли уделять время
более интересной работе и сосредоточиться на решении реальных задач.
Повсеместное применение автоматизации 95
В ходе проектирования решения подумайте, что можно автоматизировать. Рас-
смотрите возможность автоматизации любых повторяемых задач. Попробуйте
автоматизировать следующие компоненты.
• Тестирование приложения: приложение следует тестировать каждый раз,
когда вносятся изменения. Это необходимо, чтобы убедиться, что они ни-
чего не нарушили. Кроме того, ручное тестирование отнимает очень много
времени и требует значительных ресурсов. Автоматизация повторяемых
тестовых сценариев способствует ускорению разработки и запуска про-
дукта. Автоматизируйте тестирование на продакшен и используйте методы
скользящего (rolling) развертывания — такие, как канареечное и А/В-
тестирование — при публикации изменений. Канареечное тестирование
подразумевает выпуск изменений для небольшой группы пользователей,
которые оценивают их и выявляют проблемы до полноценного релиза; такой
метод выступает в качестве системы раннего оповещения о потенциальных
проблемах. При А/В-тестировании сравниваются две версии приложения
и принимается решение (на основе данных) о том, какая из них лучше под-
ходит пользователям.
• Инфраструктура IT: для автоматизации инфраструктуры можно восполь-
зоваться скриптами из категории «инфраструктура как код» — например,
Ansible, Terraform или Amazon CloudFormation. Автоматизация инфраструк-
туры позволяет создавать среды за считаные минуты, а не дни. Автоматизация
инфраструктуры как кода помогает избежать ошибок конфигурации и создает
точную копию среды.
• Журналы, мониторинг и оповещения: система мониторинга исключитель-
но важна. Если вы хотите быть уверены, что все компоненты приложения
работают правильно, и проактивно исправлять любые проблемы, вам стоит
вести постоянный мониторинг всего, что только можно. В очень больших
системах возможен только автоматизированный мониторинг. Чтобы знать,
что приложение работает гладко и так, как предполагалось, вся деятельность
по мониторингу и ведению журналов должна быть автоматизирована. Кроме
того, на основании данных мониторинга могут выполняться автоматизиро-
ванные действия — например, масштабирование системы или оповещение
команды для принятия мер.
• Автоматизация развертывания: развертывание — неоднократно повторяемая
операция, которая занимает очень много времени и во многих сценариях
реального времени задерживает итоговый запуск. Автоматизация пайплайна
развертывания за счет непрерывной интеграции и непрерывного развертыва-
ния (CI/CD) поможет придерживаться методологии Agile и быстро обновлять
функциональность продукта с частыми запусками. CI/CD помогает вносить
в приложение небольшие поэтапные изменения.
• Автоматизация безопасности: занимаясь автоматизацией, не забудьте
об автоматизации безопасности. Если кто-то попытается взломать ваше
96
Глава 2. Принципы проектирования архитектур решений
приложение, вы должны немедленно узнать об этом и действовать быстро.
Также желательно обеспечить превентивные меры, автоматизировав обработ-
ку всего входящего или исходящего трафика на границе системы и установив
оповещения для подозрительной активности.
Автоматизация помогает архитектору достичь уверенности в том, что продукт
функционирует без проблем. При проектировании приложения всегда мыслите
с точки зрения автоматизации и относитесь к ней как к одному из важнейших
параметров архитектуры. Автоматизация более подробно рассматривается
в главе 9 «Операционное совершенство».
Планирование непрерывности бизнеса
Существует риск ситуаций, когда весь регион, в котором находится ваш дата-
центр, окажется неработоспособным из-за массовых отключений электричества,
землетрясения, наводнения или атаки злоумышленников, но глобальный бизнес
должен продолжить работу. Для таких случаев у вас должен быть план аварий-
ного восстановления, предусматривающий обеспечение непрерывности бизнеса
путем подготовки достаточных ИТ-ресурсов в другом регионе (а возможно,
в других странах и даже на других континентах), чтобы бизнес мог быстро вос-
становиться и продолжить работу либо вообще обойтись без простоев.
В ходе планирования аварийного восстановления архитектор решений должен
понимать метрики RTO и RPO, используемые организацией. RTO (Recovery
Time Objective) определяет, какую продолжительность простоя может позволить
себе бизнес без значительных последствий; RPO определяет, какую часть данных
организация может позволить себе потерять. Сокращение величин RTO и RPO
означает увеличение затрат, поэтому необходимо понимать, является ли про-
стой критически важным для конкретного бизнеса и требует ли минимальных
значений RTO и RPO. Например, приложение для биржевой торговли не может
позволить себе потерять даже одну точку данных, а приложение для управления
железнодорожными сигналами не может простаивать ни секунды, потому что
от этого зависят жизни людей.
На рис. 2.13 изображена многоузловая архитектура аварийного восстановле-
ния. Основной дата-центр находится в Ирландии (Европа), а узел аварийного
восстановления — в штате Вирджиния (США), где для хостинга используется
публичная облачная платформа AWS. В таком случае бизнес сможет продолжить
работу, даже если что-то произойдет в европейском регионе или на публичной
облачной платформе. Тот факт, что план аварийного восстановления базируется
на многоузловой модели для достижения минимальных RTO и RPO, означает
отсутствие простоев и потерь данных.
Ниже перечислены самые распространенные планы аварийного восстановле-
ния. Все они будут рассмотрены в главе 11 «DevOps и фреймворк архитектуры
решений».
Планирование непрерывности бизнеса 97
Рис. 2.13. Гибридная многоузловая архитектура аварийного восстановления
• Резервное копирование и хранение: это наименее затратный план, но зна-
чения RTO и RPO в нем максимальные. В этом плане все машинные образы
серверов и снимки баз данных должны храниться на узле аварийного вос-
становления. При возникновении аварийной ситуации команда попытается
восстановить отказавший узел из резервной копии.
• Облегченная версия: в этом плане все машинные образы серверов хранятся
в резервной копии, а на узле аварийного восстановления поддерживается
небольшой сервер базы данных с непрерывной синхронизацией данных
с ведущего узла. Другие критические сервисы — такие, как Active Directory —
могут работать в малых экземплярах. В случае аварии команда пытается
восстановить работу сервера из образа и масштабировать базу данных. Об-
легченная версия обходится дороже, но имеет более низкие RTO и RPO по
сравнению с резервным копированием и хранением.
• Теплый резерв: в этом плане все экземпляры серверов приложений и баз
данных (работающих на пониженной емкости) на узле аварийного восстанов-
ления продолжают синхронизироваться с ведущим узлом. В случае аварии
команда пытается масштабировать все серверы и базы данных. Теплый резерв
обходится дороже облегченной версии, но имеет более низкие RTO и RPO.
• Многоузловая архитектура: самый затратный план с близкими к нулю
значениями RTO и RPO. В этом плане на узле аварийного восстановления
поддерживается реплика ведущего узла равной емкости, которая активно
обслуживает пользовательский трафик. В случае аварии весь трафик пере-
направляется в другую локацию.
98 Глава 2. Принципы проектирования архитектур решений
Нередко организации выбирают менее затратный вариант аварийного восста-
новления, но при этом очень важно провести тестирование, чтобы убедиться
в работоспособности средств обработки отказов. Операционное совершенство
должно стать одним из пунктов контрольного списка: необходимо гарантировать
непрерывность бизнеса в процессе восстановления после сбоев. Очень важно
обеспечить также работу приложения в продакшен-среде и его обслуживание
(поддержку) в течение многих лет. В следующем разделе рассматриваются прин-
ципы, которые делают приложение удобным в обслуживании и эксплуатации.
Проектирование с учетом эксплуатации
Операционное совершенство (operational excellence) может выделить ваше при-
ложение на фоне конкурентов за счет предоставления услуг высокого качества
с минимальными простоями. Проактивное операционное совершенство также
помогает повысить производительность службы поддержки и инженерных
команд. Удобство обслуживания, или сопровождаемость (maintainability), не-
разрывно связано с операционным совершенством. Простота обслуживания
приложения помогает сократить затраты, избежать ошибок и получить конку-
рентное преимущество.
Архитектор решений должен проектировать дизайн продукта с учетом операци-
онного совершенства, включая способы развертывания рабочей нагрузки, обнов-
ления и долгосрочной работы. Планирование ведения журналов, мониторинга
и оповещений очень важно для сохранения информации обо всех инцидентах
и быстром принятии мер в целях лучшего взаимодействия с пользователем.
Применяйте автоматизацию везде, где возможно, — как при развертывании
инфраструктур, так и при изменении кода приложения, — чтобы избежать
человеческого фактора.
При проектировании дизайна очень важно использовать методы развертыва-
ния и стратегию автоматизации, так как это позволит сократить время вывода
новых изменений на рынок без влияния на текущую эксплуатацию. Планиро-
вание операционного совершенства должно учитывать вопросы безопасности
и комплаенс, так как требования нормативных документов могут изменяться
со временем и приложение должно им соответствовать.
Обслуживание может быть как проактивным, так и реактивным; например, при
выходе новой версии операционной системы можно запланировать немедлен-
ную смену платформы для модернизации приложения или же организовать
мониторинг работоспособности системы и дождаться завершения срока жизни
продукта перед внесением каких-либо изменений. В любом случае изменения
должны вноситься инкрементно, с возможностью отката. Для применения
таких изменений можно автоматизировать весь процесс, создав пайплайн С1/
CD. Для запуска можно запланировать А/В-тестирование или сине-зеленое
развертывание1.
1 Процесс развертывания обновлений без перерывов в обслуживании. — Примеч. перев.
Преодоление архитектурных ограничений 99
Чтобы обеспечить готовность продукта к эксплуатации, при проектировании
архитектуры необходимо предусмотреть соответствующие документы и ме-
ханизмы обмена знаниями — например, ранбук (пошаговые инструкции по
выполнению типовых задач) и плейбук (последовательность действий при
реагировании на типовые инциденты). Это позволит быстро отреагировать на
возможные инциденты. Используйте анализ первопричин при составлении от-
четов, чтобы определить, почему возникла проблема, и принять меры к тому,
чтобы она не повторялась.
Операционное совершенство и поддержка — нескончаемый процесс; каждое
событие и отказ в ходе эксплуатации дают возможность внести улучшения на
основе опыта прошлых ошибок. Анализируйте операции и сбои, эксперимен-
тируйте и совершенствуйтесь. Эти вопросы более подробно рассматриваются
в главе 9 «Операционное совершенство».
В главе 1 «Архитекторы решений в организациях» вы узнали об ограничениях,
которые архитектору приходится учитывать и баланс которых необходимо
выдерживать. Ограничения — один из важнейших принципов, который будет
рассмотрен в следующем разделе.
Преодоление архитектурных ограничений
При проектировании архитектуры приложения приходится учитывать основные
ограничения: по затратам, времени, бюджету, объему поставки, графику и ре-
сурсам. При проектировании решений важно продумать, как эти ограничения
преодолевать. Рассматривайте ограничения не как препятствия, а как вызовы,
с которыми необходимо справиться, — ведь вызовы всегда подталкивают к ин-
новациям.
Архитектор решений должен определять допустимые компромиссы касательно
ограничений. Например, затраты на высокопроизводительное приложение ра-
стут, если приходится добавлять кэширование на нескольких уровнях архитек-
туры. Тем не менее в отдельных случаях затраты важнее производительности;
чаще всего это касается систем для внутренних пользователей, в которых про-
изводительность напрямую не влияет на доход компании. Иногда занять долю
рынка важнее, чем запускать полнофункциональный продукт, и приходится
выбирать между широтой охвата и скоростью выпуска. В таких сценариях можно
выбрать модель минимально жизнеспособного продукта, или MVP (Minimum
Viable Product); вы больше узнаете о нем в следующем разделе.
Технологические ограничения особенно актуальны в крупных организациях,
так как вносить изменения в сотни систем может быть непросто. При проекти-
ровании приложений рекомендуется использовать самую распространенную
в организации технологию. Кроме того, необходимо убедиться, что приложение
способно обновляться, если будут внедрены новые технологии, и что к нему
можно подключать компоненты, построенные на другой платформе.
100 Глава 2. Принципы проектирования архитектур решений
Модель RESTful-сервисов удобна, если командам разработки разрешается при-
менять любую технологию. Достаточно предоставить URL-адрес, по которому
будут доступны сервисы. Даже унаследованные системы (например, мейнфрей-
мы) могут быть интегрированы в новую систему при помощи API-обертки, и это
помогает справляться с технологическими сложностями.
В этой книге вы узнаете больше о том, как преодолеть различные архитектурные
ограничения. В этом помогает, в частности, метод MVP, благодаря которому
можно построить продукт, ориентированный на клиента.
Метод MVP
Чтобы решение было успешным, всегда ставьте клиента на первое место. Ис-
ходите из его потребностей: определите, что для него важно, и планируйте по-
ставку решения адаптивно.
MVP — стратегия разработки, используемая для создания новых продуктов или
веб-сайтов с минимальной функциональностью, необходимой для удовлетво-
рения первых пользователей и проверки концепции продукта на ранней стадии
разработки. В этом методе исходная версия продукта включает только базовую
функциональность, которая позволяет развернуть продукт. Его цели — быстро
предоставить ценность для клиента, минимизировать затраты на разработку
и максимально быстро получить обратную связь от клиентов, чтобы вносить
дальнейшие изменения и совершенствовать продукт.
В одном из популярных методов расстановки приоритетов в списке требований
клиентов — MoSCoW — требования делятся на следующие категории.
• Необходимые (Must have): требования, критичные для клиентов, без которых
запуск продукта невозможен.
• Желательные (Should have): требования, соответствие которым очень жела-
тельно для клиентов, когда они начнут пользоваться приложением.
• Возможные (Could have): требования, которым было бы неплохо соответ-
ствовать, но несоблюдение которых не повлияет на желаемую функциональ-
ность приложения.
• Избыточные (Won’t have): требования, отсутствия которых клиенты могут
даже не заметить.
Запланируйте MVP для клиента с необходимыми (must-have) требованиями,
которые должны войти в следующую итерацию поставки. При такой поэтапной
поставке вы сможете эффективно использовать свои ресурсы и справиться
с недостатком времени, бюджета, объема поставки и ресурсов. Подход MVP
помогает определить потребности заказчика и не проектировать все подряд, не
зная, обладает ли та или иная функциональность ценностью для клиента. Та-
кой подход, ориентированный на клиента, помогает эффективно использовать
ресурсы и сокращает их потери.
Итоги
101
На рис. 2.14 представлена оценка MVP для производства грузовых машин.
Клиенту нужна машина, которую он получит на начальном этапе, а вы буде-
те совершенствовать процесс на основании требований и обратной связи от
клиента.
Рис. 2.14. Подход MVP к построению решения
Как только клиент получит свою первую (полностью работоспособную) машину,
он может определить, понадобится ли ему более мощная или более крупная ма-
шина для перевозки больших грузов. На основании этой информации произво-
дитель может построить 6-, 10- и даже 18-колесный грузовик. Пошаговый подход
позволяет создавать работоспособные продукты с важнейшей функционально-
стью, которую клиенты могут использовать, а команда — совершенствовать на
основании требований клиентов.
Метод MVP помогает эффективно использовать ограниченные ресурсы, что
позволяет выделить больше времени на разработку качественного продукта
и уточнение объема поставки — по сравнению с методом, при котором вы соз-
даете 18-колесную машину только для того, чтобы позже узнать, что клиенту
было достаточно 6-колесной.
Передача клиенту работоспособного продукта на ранней стадии разработки дает
представление о том, на что следует направить усилия. Так как ваше приложение
уже начало приносить доход, вы можете представить реальные сценарии исполь-
зования, чтобы запросить дополнительные ресурсы для выполнения требований.
Итоги
В этой главе приведен подробный обзор принципов проектирования, не-
обходимых для разработки архитектур эффективных систем. Сначала мы
рассмотрели проектирование масштабируемых архитектур, дав подробное
описание упреждающей и реактивной стратегий масштабирования, а также
способы масштабирования архитектур, включая стратегии для статического
контента, управление сессиями для масштабирования серверов приложений
и масштабирование баз данных. Также мы обсудили такое важное свойство,
как эластичность.
Затем мы перешли к исследованию архитектур с высокой доступностью и устой-
чивостью. При этом особо подчеркнули важность отказоустойчивости и ис-
пользования заменяемых ресурсов для проектирования надежных систем.
102 Глава 2. Принципы проектирования архитектур решений
Специальный раздел посвящен производительности; в нем показано, как строить
системы, оптимально работающие в разных условиях.
Затем мы рассмотрели принцип слабой связанности и подчеркнули его важ-
ность в современных архитектурах, после чего перешли к подходу «сервисы,
а не серверы», занимающему центральное место в парадигме бессерверных
вычислений. В главе также подчеркивалась важность проектирования на ос-
нове данных и использования данных для принятия обоснованных решений
о системной архитектуре, а также необходимость обеспечивать безопасность.
Также мы затронули вопросы доступности и удобства использования при про-
ектировании приложений.
Следующим пунктом стала расширяемая и future-proof (защищенная от уста-
ревания, адаптируемая к будущим изменениям) архитектура; особое внимание
уделялось интероперабельности и портируемости — свойствам, гарантирующим,
что системы смогут эволюционировать и адаптироваться к изменяющимся
потребностям. Мы рассмотрели применение автоматизации во всех аспектах
системной архитектуры как средства повышения эффективности и сокращения
частоты ошибок.
Также была подчеркнута важность проектирования с учетом непрерывной
работы бизнеса, простоты обслуживания и обновления системы. Наконец, мы
затронули тему преодоления архитектурных ограничений и привели краткое
описание стратегий выявления и устранения ограничений конкретной архи-
тектуры. Также был рассмотрен метод MVP как инструмент быстрой проверки
выбора архитектуры.
В следующей главе мы поговорим о различных стратегиях и методологиях
облачной миграции. Речь пойдет о том, как компании переводят свою инфра-
структуру, приложения и данные на облачные платформы. Кроме того, в главе
будут описаны тонкости проектирования и реализации гибридной облачной
архитектуры, которая объединяет локальную инфраструктуру с облачными
сервисами, предоставляя гибкое и масштабируемое решение.
ГЛАВА 3
МИГРАЦИЯ НА ОБЛАЧНЫЕ
ПЛАТФОРМЫ
И ПРОЕКТИРОВАНИЕ
ОБЛАЧНЫХ АРХИТЕКТУР
Организации должны непрерывно привлекать новых клиентов, удовлетворяя
их потребности и при этом работая в высококонкурентной среде. Современные
организации должны быть более адаптивными, чтобы реагировать на растущие
запросы клиентов, а это требует быстрого масштабирования до миллионов кли-
ентов и обратного масштабирования по мере необходимости без последствий для
бюджета. Облачная миграция может стать средством для достижения гибкости
и скорости. Облачные платформы делают возможным частый выпуск приложе-
ний и сокращение затрат за счет применения автоматизации и консолидации
дата-центров.
Облачные технологии становятся необходимыми для любой корпоративной
стратегии. Многие организации сокращают затраты, перемещаясь на публичные
облачные платформы, причем, помимо экономии, они превращают начальные
капитальные вложения в текущие затраты. Многие стартапы, родившиеся за
последнее десятилетие, начинали с облачных платформ и использовали об-
лачную инфраструктуру для быстрого роста. Компании, переходящие на об-
лачные платформы, должны сосредоточиться на стратегиях облачной миграции
и гибридных решениях.
Такие публичные облачные платформы, как Amazon Web Services (AWS),
Microsoft Azure и Google Cloud Platform (GCP), становятся основными
площадками для хостинга приложений, поэтому каждый архитектор должен
знать стратегии и методы миграции в облако. В этой главе вы познакоми-
тесь с различными аспектами облачных технологий и начнете развивать
«облачное мышление», которое также поможет лучше понять материал сле-
дующих глав.
104 Глава 3. Миграция на облачные платформы
В этой главе рассматриваются следующие темы.
• Публичные, частные и гибридные облачные платформы.
• Архитектура решения в публичном облаке.
• Облачно-ориентированные архитектуры.
• Создание стратегии облачной миграции.
• Выбор облачной стратегии.
• Последовательность действий при облачной миграции.
• Оптимизация приложений на облачных платформах.
• Создание гибридной облачной архитектуры.
• Мультиоблачные решения.
• Реализация CloudOps.
К концу этой главы вы узнаете о преимуществах облачных платформ и разбе-
ретесь в различных стратегиях и последовательности действий при облачной
миграции. Также вы узнаете о гибридных облачных архитектурах, мультиоблач-
ных решениях и реализации CloudOps.
Публичные, частные и гибридные
облачные платформы
Существуют три разновидности облачных моделей: публичные, частные и ги-
бридные.
Публичные облачные платформы строятся на стандартной модели вычислений,
в которой поставщик сервисов предоставляет клиентам онлайн-доступ к различ-
ным ресурсам (виртуальным машинам, приложениям, пространству хранения
и т. д.). В модели облачных вычислений провайдер публичной облачной платфор-
мы предоставляет по требованию доступ к ИТ-ресурсам (серверам, базам данных,
сети, хранилищу данных), которые могут использоваться организациями через
защищенные веб-интерфейсы или при помощи специальных приложений через
интернет. Такие облачные сервисы предлагают модель оплаты по факту потреб-
ления, и в большинстве случаев клиент платит только за сервисы, которые он
реально использует; это снижает его затраты за счет оптимизации ИТ-ресурсов.
Публичные облачные платформы можно рассматривать как аналог модели
электроснабжения: вы включаете свет и платите только за фактически по-
требленное количество. Как только свет выключается, вы перестаете платить
за него. Эта модель избавляет потребителя от сложных задач: генерирования
энергии турбинами, обслуживания системы и формирования инфраструктуры.
Весь сервис используется по упрощенной схеме.
Кроме снижения затрат, основные провайдеры публичных облачных плат-
форм (такие, как AWS, GCP, Microsoft Azure, Alibaba и Oracle Cloud Platform
(OCP)) способствуют инновациям за счет расширения своих технологических
Архитектура решения в публичном облаке 105
платформ через облако. Эти поставщики отработали масштабируемость и соз-
дание перспективных архитектур на основе машинного обучения и аналитики.
Публичные облачные платформы предоставляют доступ к этим передовым
технологиям и возможность использовать их для улучшения проектируемых
архитектур.
Частные (или локальные) облачные платформы регистрируются на одну
конкретную организацию, которая становится их владельцем. Частные обла-
ка используются как реплики или расширения существующих дата-центров
компании. В отличие от них, публичные облачные платформы предлагают
совместную аренду; это означает, что виртуальные серверы нескольких клиен-
тов используют один физический сервер. Впрочем, они также могут назначать
выделенные физические серверы, если это понадобится клиенту по условиям
лицензии или комплаенса.
Третью модель — гибридную — выбирают крупные корпорации, которые
перемещают свою рабочую нагрузку из локальной среды в облако. При этом
у них остается старое приложение, которое невозможно переместить в облако
напрямую, или, возможно, лицензированное приложение, которое по условиям
лицензии должно оставаться локальным, или из-за требований комплаенса при-
ходится осуществлять локальную защиту данных. Таким образом, компания
вынуждена поддерживать частичную локальную среду и перемещать другие
приложения на публичную облачную платформу. Иногда организация пере-
носит в облако среды тестирования и разработки, оставляя продакшен-среды
локально. Гибридная модель может изменяться в зависимости от облачной
стратегии организации.
Так как на рынке действуют разные облачные провайдеры, появляется тенденция
к мультиоблачным решениям. В этих решениях компании распределяют свою
рабочую нагрузку между разными провайдерами публичных облачных плат-
форм, чтобы пользоваться сильными сторонами каждой облачной технологии
или предоставить своей команде выбор в зависимости от ее набора навыков.
В следующем разделе мы подробнее рассмотрим публичные облачные техноло-
гии и разберемся, как они становятся важнейшей технологической платформой
для бизнеса.
Архитектура решения в публичном облаке
Архитектура решений в облаке начинает играть все более важную роль. Сейчас
она фактически стала «новой нормой», и все больше компаний решают пере-
вести на нее свою рабочую нагрузку. Публичные облачные платформы стали
критическим фактором, питающим рост стартапов, так как нужны лишь не-
большие начальные инвестиции вместо значительных затрат на дорогостоящие
локальные решения. Это позволяло организациям проводить эксперименты,
быть адаптивными и внедрять инновации.
106 Глава 3. Миграция на облачные платформы
Самое замечательное в архитектуре облачных вычислений заключается в том,
что они обеспечивают сквозное представление всех архитектурных компонентов,
необходимых для управления всей средой решений, включая фронтенд-плат-
формы, платформы разработки приложений, серверы, хранилища данных, базы
данных, автоматизацию, поставку и сети.
В следующем разделе архитектура публичных облачных платформ рассматри-
вается более подробно.
Публичная облачная архитектура
Стандартное определение публичной облачной архитектуры — полностью
виртуализированная среда, доступная по сети интернет и через частную сеть.
Однако поставщики таких облачных платформ в последнее время стали пред-
лагать локальные физические инфраструктуры, чтобы стимулировать при-
нятие гибридных облачных решений. Публичные облачные платформы пре-
доставляют мультитенантную модель (совместную аренду), при которой
ИТ-инфраструктура — например, хранилища данных и вычислительные мощно-
сти — совместно используется разными клиентами; при этом она изолируется на
программном и логическом сетевом уровне, и рабочие нагрузки разных клиентов
не мешают друг другу. Организации также могут обеспечивать изоляцию сетевого
уровня в публичном облаке, чтобы создать собственный виртуальный частный
облачный аналог логического дата-центра. Для удовлетворения нормативных
требований организаций публичные облачные платформы также предоставляют
выделенные физические экземпляры; они бывают доступны онлайн, но этот
вариант встречается не так часто.
Публичные облачные хранилища обеспечивают высокую устойчивость и до-
ступность за счет создания модели избыточности, использующей несколько
дата-центров и надежный механизм репликации данных. Это способствует до-
стижению архитектурной устойчивости и простой масштабируемости.
Существуют три основные разновидности моделей публичных облачных вычис-
лений (рис. 3.1). Для сравнения на диаграмме также представлены локальные
решения.
На рис. 3.1 можно сравнить обязанности клиента в локальных средах с моделями
облачных вычислительных сервисов. В локальной среде клиенту приходится
управлять всем, тогда как в модели облачных вычислений клиент может дове-
рить часть своих обязанностей провайдеру и сосредоточиться на потребностях
бизнеса. Ниже перечислены высокоуровневые подробности сервисов, предо-
ставляемых разными моделями облачных вычислений.
• laaS (Infrastructure as a Service, «инфраструктура как сервис»): в этой модели
облачный провайдер предоставляет инфраструктурные ресурсы (например,
серверы для вычислений, сетевые компоненты, пространство для хранения
данных) в виде управляемых сервисов. Это позволяет клиентам пользоваться
Архитектура решения в публичном облаке 107
ИТ-ресурсами, не беспокоясь о лишних затратах на поддержание работы
дата-центра (нагрев и охлаждение, монтирование, физическая безопасность
ит. д.).
• PaaS (Platform as a Service, «платформа как сервис»): модель PaaS добавляет
уровень, на котором облачный провайдер берет на себя управление ресурсами,
необходимыми для платформы разработки: операционной системой (ОС),
поддержкой и обновлением программного обеспечения, а также ресурсами
инфраструктуры. Модель PaaS помогает команде сосредоточиться на на-
писании бизнес-логики и на работе с данными. Разработчики избавлены от
хлопот с поддержкой платформы.
• SaaS (Software as a Service, «программное обеспечение как сервис»): модель
SaaS добавляет дополнительный уровень абстракции поверх моделей PaaS
и laaS. На этом уровне облачный провайдер или разработчик ПО предостав-
ляет готовые к использованию программы, а вы платите за сервис. Пример:
сервисы электронной почты, такие как Gmail, Yahoo Mail, AOL и т. д., где вы
получаете собственное пространство для сообщений как сервис и не нужно
беспокоиться об используемых приложениях или инфраструктурах.
Четвертая, еще только формирующаяся, модель FaaS (Function as a Service,
«функция как сервис») становится популярной при построении бессерверных
архитектур с использованием сервисов, включая AWS Lambda. Бессерверная
архитектура более подробно рассматривается в главе 5 «Паттерны проектиро-
вания облачно-ориентированных архитектур».
Ниже приведен краткий обзор провайдеров публичных облачных платформ.
Локальная модель
Хранилище
Хранилище
Инфраструктура
как сервис (laaS)
Приложение
и данные
Приложение
и данные
Операционная система
и среда времени
выполнения
Операционная система
и среда времени
выполнения
Сервер
и виртуализация
Сервер
и виртуализация
Ответственность клиента
Платформа
как сервис(PaaS)
Приложение
и данные
Операционная система
и среда времени
выполнения
Сервер
и виртуализация
Хранилище
Сеть
Программное обеспечение
как сервис(SaaS)
Приложение
и данные
Операционная система
и среда времени
выполнения
Сервер
и виртуализация
Хранилище
[ | Предоставляется провайдером
Рис. 3.1. Разновидности моделей облачных вычислений
108 Глава 3. Миграция на облачные платформы
Популярные провайдеры публичных облачных платформ
На глобальном облачном рынке доминируют четыре основных провайдера. По
данным отчета Statista за 2023 год, AWS лидирует с долей рынка 32 %, предо-
ставляя широкий спектр облачных сервисов, включающих вычисления, хранение
данных, сетевые коммуникации, базы данных, аналитику, машинное обучение
и ИИ. AWS используется в примерах нашей книги.
Microsoft Azure следует вплотную за AWS с долей рынка 24 %, особенно ярко
проявляя себя в корпоративных приложениях и гибридных облачных вычисле-
ниях. GCP удерживает 11 % рынка и быстро расширяется; платформа особенно
знаменита своими достижениями в машинном обучении и знаниями в области
ИИ. Alibaba Cloud удерживает четвертое место с 4 % рынка, лидируя в Азиат-
ско-Тихоокеанском регионе. Эти четыре провайдера контролируют более 70 %
глобального облачного рынка.
Среди других важных участников можно выделить Oracle, IBM Cloud, Tencent
Cloud и Salesforce. Подробный отчет доступен по адресу: https://www.statista.com/
chart/18819/worldwide-market-share-of-leading-cloud-infrastructure-service-providers/.
Так как облачная функциональность и модели затрат сильно отличаются от
традиционных, давайте разберем, как разработать облачно-ориентированный
подход к проектированию архитектуры.
Облачно-ориентированная архитектура
Облачно-ориентированная архитектура оптимизирует архитектуры систем так,
чтобы пользоваться преимуществами облака. Типичная локальная архитектура
обычно строится для фиксированной инфраструктуры, так как добавление но-
вых ИТ-ресурсов (например, серверов или вычислительных мощностей) может
требовать значительного времени, затрат и усилий. В облаке же плата взимается
за фактическое использование, а автоматизация упрощает возможные измене-
ния — например, масштабирование серверов в большую или меньшую сторону
без проблем с продолжительными циклами поставки. Облачно-ориентированная
архитектура сосредоточена на масштабировании по требованию, распределенных
решениях и замене отказавших компонентов вместо их ремонта.
В облачно-ориентированных архитектурах обычно создаются автоматизиро-
ванные операции восстановления, масштабируемости, самовосстановления
и высокой доступности, с использованием облачных средств непрерывной инте-
грации (CI), развертывания и автоматизации инфраструктуры. Это способствует
непрерывной оптимизации приложения в части затрат и производительности
с применением новых облачных возможностей, которые выпускаются и совер-
шенствуются практически ежедневно.
Провайдеры публичных облачных платформ распространяют свою глобальную
инфраструктуру по всему миру, что помогает приложению масштабировать-
ся глобально и рядом с пользователями. Чтобы стимулировать переход, все
Архитектура решения в публичном облаке 109
облачные сервисы предоставляют бесплатный тариф обслуживания (free-tier)
с большим объемом учебных ресурсов, чтобы вы могли попробовать и получить
знания в этой области.
Облачно-ориентированный подход позволяет специалистам развивать инно-
вационное мышление и реализовывать свои идеи немедленно, не дожидаясь
завершения длительного цикла инфраструктуры.
При использовании облачных технологий клиентам не нужно планировать
избыточную емкость для обработки пиковых нагрузок (например, периода
праздничных покупок для розничной торговли); доступная эластичность
мгновенно предоставит ресурсы для повышенного спроса. Это значительно
экономит затраты и улучшает пользовательские взаимодействия. Чтобы не
отстать от конкурентов, организациям приходится действовать быстро и не-
стандартно.
Облачные платформы позволяют предприятиям быстро развернуть свою
инфраструктуру по всему миру и получить доступ к технологиям, кото-
рые ранее были им недоступны. Некоторые передовые технологии из этой
категории:
• большие данные и аналитика;
• машинное обучение и ИИ;
• интернет вещей (1оТ);
• блокчейн;
• генеративный ИИ.
Построение архитектуры решения для облака отличается от работы архитек-
тора для обычных организаций. При переходе в облако необходимо развить
облачное мышление и понять, как пользоваться встроенными возможностями
облачных платформ. Для облачного мышления следует руководствоваться
моделью оплаты по факту потребления, а это означает, что вы должны следить
за правильной оптимизацией рабочей нагрузки и запускать серверы, только
когда это необходимо.
@При проектировании для облачных платформ архитектор решений должен
иметь целостное представление обо всех компонентах, относящихся
к производительности, масштабированию, высокой доступности, аварийному
восстановлению, отказоустойчивости, безопасности и автоматизации.
Другие области оптимизации — облачно-ориентированные механизмы мони-
торинга и оповещений. Возможно, вам не придется переносить в облако су-
ществующие сторонние средства мониторинга с локальных площадок, так как
облачные средства мониторинга будут более эффективными и избавят вас от
затрат на дорогостоящие сторонние лицензионные программы. Кроме того, у вас
появляется возможность за считаные минуты провести развертывание в любой
110 Глава 3. Миграция на облачные платформы
части мира. Не ограничивайтесь конкретным регионом; используйте модель
глобального развертывания для построения более эффективных механизмов
высокой доступности и аварийного восстановления.
Облачные платформы предоставляют отличные возможности для автоматиза-
ции; по сути, с ними можно автоматизировать все. Автоматизация сокращает
ошибки, ускоряет выход на рынок и дает значительную экономию за счет эф-
фективного использования человеческих ресурсов и избавления сотрудников
от выполнения однообразных и скучных операций.
Облачные платформы используют модель разделения ответственности, в ко-
торой облачные провайдеры отвечают за защиту физической инфраструктуры.
При этом безопасность приложения и его данных полностью зависит от клиента.
Следовательно, очень важно изолировать вашу среду и осуществлять контроль
безопасности, используя облачные инструменты мониторинга, оповещений
и автоматизации.
Проектирование облачно-ориентированных
архитектур
В разных организациях могут существовать разные мнения по поводу облачно-
ориентированных архитектур, но все сходятся на том, что облачно-ориентиро-
ванное мышление направлено на максимально эффективное использование
всех облачных возможностей. Истинная облачно-ориентированная архитектура
означает проектирование приложения, начиная с самых его основ, с учетом об-
лачной специфики.
Облачно-ориентированное проектирование не означает хостинга приложения на
облачной платформе; оно направлено на эффективное использование сервисов
и возможностей, предоставляемых такой платформой. В частности:
• контейнеризация монолитной архитектуры в микросервисе и создание пай-
плайна CI/CD для автоматического развертывания;
• построение бессерверного приложения с такой технологией, как AWS Lambda
FaaS и Amazon DynamoDB (управляемая база данных NoSQL в облаке);
• создание бессерверных озер данных — например, с использованием Amazon
S3 (управляемого сервиса хранения объектов), AWS Glue (управляемого
кластера Spark для ETL) и Amazon Athena (управляемого кластера Presto
для ситуативных запросов);
• использование облачно-ориентированного сервиса мониторинга и ведения
журналов (например, Amazon CloudWatch);
• использование облачно-ориентированного сервиса аудита (например, AWS
CloudTrail).
На следующей диаграмме (рис. 3.2) представлен пример облачно-ориентиро-
ванных бессерверных архитектур для приложения микроблогов.
Архитектура решения в публичном облаке 111
Шлюз Amazon API
Пользовательский запрос
Облако AWS
Рис. 3.2. Облачно-ориентированная архитектура приложения
для ведения микроблогов
На этой диаграмме представлено использование облачно-ориентированных
бессерверных сервисов в облаке AWS. Здесь Amazon Route 53, управляющий
сервисом DNS, осуществляет маршрутизацию пользовательских запросов.
Lambda — сервис для обработки кода проверки пользователя, пользовательских
профилей и страниц блогов. Все ресурсы блогов хранятся в Amazon S3, кото-
рый управляет сервисами хранения объектов, а все данные пользовательских
профилей хранятся в Amazon DynamoDB — управляемой базе данных NoSQL.
Когда пользователи отправляют свои запросы, AWS Lambda проверяет поль-
зователей и обращается к их профилям, чтобы убедиться, что у них имеется
подписка Amazon DynamoDB; после этого сервис выбирает ресурсы блога
(графику, видео, статическую разметку HTML) из Amazon S3 и отображает их
для пользователя. Такая архитектура может масштабироваться неограниченно,
так как все сервисы являются облачно-ориентированными и управляемыми,
и управлять инфраструктурой не требуется.
Такие критические факторы, как высокая доступность, аварийное восста-
новление и масштабируемость, обеспечиваются облачно-ориентированными
112 Глава 3. Миграция на облачные платформы
сервисами, чтобы вы могли сосредоточиться на разработке функциональности.
Что касается затрат, вы платите только в том случае, если запрос поступает
приложению блогов. Если никто не просматривает блог ночью, за хостинг
своего кода вы ничего не платите; оплачивается только номинальная стоимость
хранения.
Преимущество облачно-ориентированной архитектуры заключается в том, что
она позволяет командам быстро внедрять инновации и действовать адаптивно.
Она упрощает построение сложных приложений и инфраструктур. Так как
вы занимаетесь исключительно проектированием и построением своих сетей,
серверов, файловых хранилищ и других вычислительных ресурсов, физическую
реализацию можно доверить провайдеру облачных вычислений.
Другие преимущества облачно-ориентированных архитектур.
• Быстрое масштабирование по требованию: вы можете запросить необходи-
мые ресурсы, когда это действительно нужно. Вы платите только за то, что
реально используете.
• Быстрая репликация: «инфраструктура как код» означает, что вы строите
один раз, а потом делаете репликацию. Вместо того чтобы строить инфра-
структуру вручную, вы структурируете ее в виде серии скриптов или прило-
жений. Создание инфраструктуры на программном уровне позволяет строить
и перестраивать ее по требованию, когда это понадобится для разработки
или тестирования.
• Простота создания и удаления: в облаке сервисы предоставляются по тре-
бованию, поэтому построить большую экспериментальную систему доста-
точно просто. Она может включать кластер масштабируемых веб-серверов
и серверов приложений, несколько баз данных, терабайты пространства
хранения данных, управляющие приложения и средства мониторинга.
Это все легко убрать после завершения эксперимента и уменьшить таким
образом затраты.
Для облачно-ориентированных архитектур существует много других примеров
в области хранения, сетей и автоматизации. Особенности этой архитектуры
подробно рассматриваются в главе 5 «Паттерны проектирования облачно-
ориентированных архитектур».
В следующем разделе рассматриваются различные стратегии облачной миграции.
Стратегии облачной миграции
Выбранная облачная стратегия поможет определить стратегию миграции и рас-
ставить приоритеты для приложений. Ниже перечислены некоторые критерии
для запуска стратегий облачной и гибридной миграции:
• дата-центр нуждается в технологическом обновлении;
Стратегии облачной миграции 113
• у дата-центра истекает срок аренды;
• у дата-центра исчерпаны емкости хранения данных и вычислительные мощ-
ности;
• требуется модернизация приложения;
• освоение передовых технологий: генеративный ИИ, расширенная аналитика,
машинное обучение, 1оТ и т. д;
• требуется оптимизация ИТ-ресурсов для экономии эксплуатационных рас-
ходов;
• планирование аварийного восстановления и эксплуатационная устойчи-
вость;
• использование сети распространения контента (CDN) для веб-сайта;
• сокращение исходных капитальных затрат и исключение затрат на обслу-
живание;
• повышение эффективности и производительности труда;
• повышение адаптивности бизнеса.
Разные организации применяют разные стратегии, и при переходе на облачные
платформы единственно верного пути не существует. Популярные сценарии
использования — размещение сред разработки и тестирования в облаке, чтобы
у разработчиков была возможность действовать более адаптивно и быстро. По-
скольку хостинг веб-приложений в облаке дешевле и проще, компании начинают
использовать облачные платформы для цифровой трансформации, организуя
облачный хостинг своих веб-сайтов и цифровых активов.
Важно не только разработать приложение для веб-браузера, но и убедиться,
что оно доступно на смартфонах и планшетах. Облако упрощает такие преоб-
разования. Обработка данных и аналитика — еще одна область, ради которой
переходят на облачные технологии, поскольку они позволяют быстрее и дешевле
собирать, хранить, анализировать и передавать данные.
Переход на облачные технологии не сводится к выбору платформы, проектиро-
ванию безопасности и эксплуатации. Помимо технологий, следует учитывать
человеческий фактор, процессы и культуру в компании. Для успеха облачной
миграции необходимо согласовать цели с руководством и обеспечить вовлечен-
ность команды через обучение. Чтобы гарантировать плавный переход на об-
лачную платформу, следует сформировать соответствующее вйдение в рамках
всей организации.
Часто в проектах миграции применяются сразу несколько стратегий и различные
инструменты. Стратегия миграции влияет на время, которое займет переход,
и способы группировки приложений для процесса миграции. На следующей
диаграмме (рис. 3.3) представлены некоторые часто применяемые стратегии
для миграции существующих приложений в облако.
114
Глава 3. Миграция на облачные платформы
Повторная покупка
Рис. 3.3. Стратегии облачной миграции
Как показано на диаграмме, можно переместить сервер или приложения из
исходной среды в облако «как есть» (то есть по методу lift-and-shift). Чтобы
ресурс заработал в облаке, его миграция требует минимальных изменений.
Облачно-ориентированный подход (cloud-native) подразумевает рефакторинг
приложения, чтобы в полной мере использовать его облачно-ориентированную
функциональность — например, преобразование монолитных приложений
в микросервисы.
Если вы имеете дело с унаследованным приложением, которое невозможно
переместить, или же приложение несовместимо с облаком, его можно заменить
облачно-ориентированным продуктом SaaS или сторонним решением.
Организация также может применить комбинированную стратегию миграции.
Например, если операционная система, на которой работает приложение, уста-
рела и ее поддержка скоро прекратится, это повод не просто обновить ОС, но
и перенести приложение в облако для большей гибкости. В таком случае вы,
вероятно, выберете метод смены платформы (replatform), перекомпилировав код
для новой версии ОС и проверив всю его функциональность. После тестирования
приложение можно перенести в ОС на сервере, предоставленном облачным про-
вайдером. Если требуется замена платформы (например, переход с устаревшей
CRM-системы на SaaS- решение от Salesforce), вы можете выбрать стратегию
Стратегии облачной миграции 115
вывода из эксплуатации и повторной покупки (retire and repurchase). Чтобы
преобразовать приложение из монолитного в микросервисное для повышения
адаптивности, можно провести его рефакторинг (refractoring).
Определять решение о миграции приложений и стратегию миграции необ-
ходимо в соответствии с приоритетами бизнес-целей. Например, если основ-
ным фактором является экономическая эффективность, стратегия миграции
обычно включает массовую миграцию, в значительной мере ориентированную
на перемещение «как есть» (lift-and-shift). С другой стороны, если главной
целью являются адаптивность и инновации, для стратегии облачной миграции
предпочтителен облачно-ориентированный подход (переработка архитектуры
и рефакторинг). Рассмотрим каждую из упомянутых стратегий в следующих
подразделах.
Миграция lift-and-shift
Lift-and-shift — самый быстрый режим миграции; он требует минимальных уси-
лий. Однако этот режим должен использовать преимущества облачных функций.
Рассмотрим самые распространенные стратегии миграции (рехостинг, смена
платформы, релокация) при использовании метода lift-and-shift.
Рехостинг
Рехостинг (rehosting) — быстрый, предсказуемый, повторяемый и экономичный
механизм, что делает его предпочтительным методом миграции на облачные
платформы. Кроме того, рехостинг считается одной из самых быстрых страте-
гий облачной миграции, при которой сервер или приложение перемещаются
из исходной локальной среды в облако. В процессе миграции в ресурсы могут
вноситься минимальные изменения.
Клиенты часто используют рехостинг, чтобы быстро провести миграцию своих
приложений в облако, а затем, когда ресурсы начнут работать в облаке, сосре-
доточиться на оптимизации. Этот метод позволяет реализовать экономические
преимущества использования облачных платформ.
Клиенты обычно применяют рехостинг в следующих сценариях:
• создание временной среды для разработки и тестирования;
• выполнение на серверах пакетных программ — например, SAP или Microsoft
SharePoint;
• отсутствие у приложения активной дорожной карты.
Хотя рехостинг предназначен для пакетного ПО и ускоряет переход на облачную
платформу, возможно, для его использования придется обновить нижележащие
платформы приложений (например, операционные системы). В такой ситуации
для облачной миграции можно воспользоваться методом смены платформы.
116
Глава 3. Миграция на облачные платформы
Смена платформы
Проект облачной миграции можно инициировать, когда срок службы версии
ОС, сервера или базы данных подходит к концу, — например, при обновлении
ОС веб-сервера до Microsoft Windows 2022, обновлении базы данных до вер-
сии Oracle 23с и т. д. Стратегия смены платформы (replatform) подразумевает
обновление платформы как часть проекта облачной миграции без изменения
архитектуры приложения. В рамках миграции можно обновить ОС или при-
ложение до новой версии.
При использовании стратегии смены платформы может возникнуть необходи-
мость переустановить приложение в среде назначения, что приведет к измене-
ниям в приложении. Тогда нужно тщательно протестировать приложение, чтобы
проверить его эксплуатационную эффективность после миграции.
Смена платформы может быть обусловлена следующими причинами:
• переход с 32-разрядной версии ОС на 64-разрядную;
• изменение ядра базы данных;
• обновление версии приложения;
• обновление ОС;
• обновление ядра базы данных;
• использование преимуществ управляемых сервисов, предоставляемых облач-
ными провайдерами (управляемое хранилище, базы данных, развертывание
приложения, средства управления).
Смена платформы помогает перейти на более продвинутую платформу прило-
жения в процессе миграции в облако. Приложение можно переместить в облако,
если оно развернуто в контейнерах или VMWare.
Рассмотрим теперь стратегию релокации.
Релокация
Приложение может быть развернуто с использованием контейнеров или эк-
земпляров VMWare в локальном дата-центре. Для перемещения таких рабочих
нагрузок в облако используется ускоренная стратегия миграции: релокация
(relocation).
Релокация помогает перемещать сотни приложений за считаные дни. Прило-
жения, базирующиеся на VMWare и контейнерных технологиях, можно рело-
цировать в облако с минимальными усилиями и сложностью.
Стратегия релокации требует лишь немного времени разработчиков на на-
чальной стадии или наличия плана тестирования и обеспечивает адаптив-
ность и автоматизацию, ожидаемую от облака. Определите существующие
конфигурации и используйте VMotion или Docker для перемещения серверов
в облако. Подробнее о Docker вы узнаете в главе 6 «Факторы производитель-
ности».
Стратегии облачной миграции 117
VMotion - технология VMware, известная возможностью живой миграции. Она
f -СА- j позволяет переместить виртуальный экземпляр с одного физического хоста
V z s 4J на другой без прерывания сервиса.
В процессе миграции приложения в облако возникает возможность перестроить
и переработать архитектуру всего приложения, чтобы оно стало более облач-
но-ориентированным. Это позволит использовать весь потенциал облачных
технологий. Рассмотрим облачно-ориентированный подход более подробно.
Облачно-ориентированный подход
Когда команда решает перейти на облачно-ориентированное решение, в крат-
косрочной перспективе это может потребовать больших усилий на начальном
этапе и замедлит миграцию в облако. Однако в долгосрочной перспективе эти
усилия окупятся, когда вы будете пользоваться всеми преимуществами облачных
технологий и внедрять инновации вашей agile-командой.
Облачно-ориентированный подход со временем значительно снижает затраты,
поскольку позволяет оптимизировать рабочую нагрузку за разумную цену при со-
хранении уровня производительности благодаря модели оплаты за фактическое
использование. Облачно-ориентированный подход включает контейнеризацию
приложения путем его перепроектирования в виде микросервиса или выбора
бессерверного подхода.
Рассмотрим методы рефакторинга и повторного приобретения для облачно-
ориентированной миграции.
Рефакторинг
Рефакторинг (refactoring) подразумевает перепроектирование и переписывание
приложения перед его миграцией в облако, чтобы сделать его облачно-ориен-
тированным. Рефакторинг повышает уровень модульности приложения (на-
пример, переходом от монолитной архитектуры к микросервисной). Переход
к микросервисной архитектуре помогает организациям создавать небольшие
независимые команды, которые полностью владеют своей частью кода, и это
способствует повышению скорости инноваций.
Облачно-ориентированные приложения проектируются с расчетом на эффек-
тивную работу в облаке. В частности, облачные платформы предоставляют
такие преимущества, как масштабируемость, безопасность, адаптивность
и экономическая эффективность.
Рефакторинг требует больших затрат времени и ресурсов перед миграцией. Этот
подход часто используется в организациях с обширным опытом использова-
ния облачных технологий или с высококвалифицированными сотрудниками.
Альтернативный вариант рефакторинга — миграция приложения в облако
с его последующей оптимизацией. Для сокращения накладных расходов на
118 Глава 3. Миграция на облачные платформы
администрирование модульной архитектуры можно использовать облачно-
ориентированные бессерверные технологии.
Несколько типичных примеров рефакторинга:
• смена платформы (например, переход с AIX на Unix);
• преобразование традиционной базы данных в облачную;
• замена промежуточного ПО (middleware);
• преобразование монолитной архитектуры приложения в микросервисную;
• переработка архитектуры приложения (например, контейнеризация или
переход к бессерверной архитектуре);
• изменение кода компонентов приложения;
• модернизация хранилищ данных для связывания организаций с клиентами.
Принятие решения о том, следует ли преобразовать приложение к микросервис-
ной архитектуре либо перестроить его для контейнеризации или бессерверной
архитектуры, требует тщательного анализа стратегических целей организации,
необходимых затрат и технических возможностей. Переход к микросервисной
архитектуре улучшает масштабируемость и гибкость, когда каждый сервис раз-
рабатывается, развертывается и масштабируется независимо от других, а это
значительно улучшает долгосрочную адаптивность и эффективность. Однако
такой подход может приводить к серьезному рефакторингу и создавать слож-
ности в координации сервисов и сетевых коммуникаций. С другой стороны,
перестройка архитектуры для перехода на контейнеризацию или бессерверные
модели может оптимизировать текущие операции, сокращать накладные рас-
ходы на инфраструктуру и улучшать скорость развертывания, однако требует
исходных вложений в разработку и адаптацию команды.
При принятии решения необходимо учитывать совместимость приложения
с новой архитектурой, опыт команды и потенциальные последствия для про-
изводительности и надежности. Микросервисы улучшают изоляцию сбоев
и упрощают более детализированное управление ресурсами, а контейнеризация
и бессерверные архитектуры оптимизируют использование ресурсов и потен-
циально сокращают затраты. Важно учитывать также факторы безопасности
и комплаенса, поскольку каждый архитектурный стиль подразумевает специ-
фические проблемы, которыми необходимо решать проактивно.
Иногда перестройка приложения требует значительных усилий. Вы, как архи-
тектор, должны оценить, позволит ли приобретение продукта SaaS добиться
более высокого коэффициента возврата инвестиций (ROI).
Давайте более подробно рассмотрим стратегию повторного приобретения
(repurchase).
Стратегии облачной миграции 119
Повторное приобретение
Для переноса ИТ-ресурсов и проектов в облако могут понадобиться серверы или
приложения, которые потребуют покупки облачно-совместимой лицензии или
версии. Например, текущая локальная лицензия приложения может потребовать
подтверждения при запуске приложения в облаке.
Существует много вариантов обработки таких сценариев лицензирования.
Можно приобрести новую лицензию и продолжить пользоваться приложени-
ем в облаке или же удалить существующую лицензию и заменить ее другой,
предназначенной для облачной платформы. Такая замена может быть частью
предложения SaaS.
Может оказаться, что облачная платформа не решает всех проблем и унаследо-
ванное приложение не выигрывает от облачной миграции. А иногда обнаружи-
ваются редко используемые приложения, которые можно удалить.
Рационализация рабочей нагрузки. Рационализация рабочей нагрузки -
стратегический процесс облачной миграции и проектирования архитектур,
направленный на консолидацию похожих сервисов для оптимизации операций
и повышения эффективности. Этот подход включает оценку и слияние
различных систем (например, разных CRM-систем) в единое решение. Его
цель - устранение избыточности, сокращение сложности и оптимизация
ресурсов в ИТ-среде организации.
Во многих компаниях рационализация рабочей нагрузки становится кри-
тической инициативой, определяющей решения о том, какие приложения
следует оставить, обновить, удалить или консолидировать. Этот процесс не
только способствует упрощению технологического стека, но и устанавли-
вает соответствие ИТ-ресурсов бизнес-целям организации, гарантируя, что
каждый сервис необходим, эффективен и вносит свой вклад в глобальные
цели организации. При помощи рационализации компании могут создавать
более адаптивные, экономически эффективные и масштабируемые ИТ-
инфраструктуры, которые особенно полезны в контексте облачной миграции
и гибридных облачных архитектур, где эффективность и адаптируемость
играют решающую роль.
В следующем разделе более подробно рассматривается стратегия «сохранение
или вывод из эксплуатации» (retain or retire).
Сохранение или вывод из эксплуатации
При проведении облачной миграции, возможно, будет достаточно переместить
только некоторые приложения. Не исключено, что какие-то приложения нужно
будет сохранить из-за технологических ограничений: например, привязанные
к локальному серверу, который переместить невозможно. С другой стороны,
можно удалить некоторые приложения и заменить их облачно-ориентирован-
ными (например, сторонние приложения для мониторинга и оповещения).
Рассмотрим обе стратегии более подробно.
120 Глава 3. Миграция на облачные платформы
Сохранение
В локальной среде могут присутствовать приложения, жизненно важные для
бизнеса, но непригодные для миграции по техническим причинам — например,
потому что ОС/приложение не поддерживается на облачной платформе. В таких
ситуациях приложение не удастся перенести на облачную платформу, но можно
продолжить выполнять его в локальной среде.
Возможно, для таких серверов и приложений будет достаточно провести только
исходный анализ, чтобы определить их пригодность к облачной миграции. Одна-
ко у сервера или приложения могут оставаться зависимости с мигрированными
приложениями. А значит, придется поддерживать связь этих локальных серверов
с облачной средой. В разделе «Создание гибридной облачной архитектуры» этой
главы вы больше узнаете о связывании локальных и облачных сред.
Возможно, вы захотите сохранить сложные старые системы в локальной среде
и расставить приоритеты, чтобы их можно было перенести позднее. Однако во
время анализа организации часто обнаруживают приложения, которые не ис-
пользуются, но остаются в системе и потребляют инфраструктурное простран-
ство. Вы можете принять решение об удалении таких приложений. В следующем
разделе стратегия удаления рассматривается более подробно.
Вывод из эксплуатации (удаление)
В процессе миграции на облачную платформу можно обнаружить:
• редко используемые приложения;
• приложения, потребляющие избыточную емкость сервера;
• приложения, в которых больше нет надобности из-за несовместимости с об-
лачной платформой.
В такой ситуации можно удалить существующую рабочую нагрузку и выбрать
другой подход, более облачно-ориентированный.
Стратегия удаления может применяться к хостам и приложениям, которые
вскоре будут выведены из эксплуатации. Также она может применяться к лиш-
ним, избыточным приложениям. В зависимости от бизнес-потребностей такие
приложения могут выводиться из эксплуатации локально, без миграции в об-
лако. К числу хостов и приложений, обычно подходящих для удаления, обычно
относятся:
• локальные серверы и хранилища, предназначенные для целей аварийного
восстановления;
• консолидация серверов для устранения избыточности;
• дубликаты ресурсов, появившиеся из-за слияний и поглощений;
• альтернативные хосты в типичной конфигурации с высокой доступностью;
• инструменты со сторонней лицензией (например, средства мониторинга
и автоматизации рабочей нагрузки), поставляемые с облаком.
Выбор стратегии облачной миграции 121
Во многих проектах миграции применяются сразу несколько стратегий, и для
каждой из них доступны разные инструменты. Стратегия влияет на время,
необходимое для миграции, и на группировку приложений для процесса
миграции. Облачная миграция — подходящий момент для проведения инвен-
таризации и удаления любых «серверов-призраков», за которые никто не от-
вечает. В следующем разделе мы сравним облачные стратегии, представленные
в этом разделе.
Выбор стратегии облачной миграции
Выбор правильной стратегии миграции имеет решающее значение для биз-
неса. При этом необходимо учитывать действующие ограничения: финансы,
ресурсы, время, квалификацию сотрудников. Усилия, которых требуют стра-
тегии, перечисленные в предыдущем разделе, можно сравнить по следующей
таблице.
Таблица 3.1. Сравнение стратегий облачной миграции
Стратегия миграции Описание Время и затраты Возможности оптимизации
Рефакторинг Изменение архитектуры приложений на модульную, чтобы сделать их более об- лачно-ориентированными
Смена платформы Миграция приложений на обновленную платформу без изменения базовой архи- тектуры
Повторная покупка Замена текущей среды пу- тем приобретения решения на основе облака
Рехостинг Быстрое перемещение при- ложений в облако без изме- нения архитектуры 1
Сохранение Приложение остается в ло- кальной среде, по крайней мере на какое-то время -
Релокация Быстрое перемещение при- ложений в облако без их изменения -
Удаление Выявление ресурсов, ко- торые перестали быть по- лезными, и вывод их из эксплуатации — —
122 Глава 3. Миграция на облачные платформы
Облачная миграция предоставляет многочисленные преимущества (масшта-
бируемость, гибкость, экономическую эффективность), но она влечет и целый
ряд рисков. Организации должны знать о потенциальных проблемах, чтобы
эффективно бороться с ними. Вот некоторые из возможных рисков.
• Потеря и утечка данных: в процессе миграции может возникнуть угроза
для конфиденциальности данных, если они не будут зашифрованы или ими
будут неправильно управлять. Гарантия целостности и безопасности данных
в процессе миграции — обязательное условие для предотвращения утечек
и несанкционированного доступа.
• Простои: миграция может привести к бездействию системы, которое отра-
зится на бизнес-операциях. Планирование и выполнение миграции по этапам
или во время пониженной нагрузки снизит последствия для непрерывности
бизнеса.
• Превышение затрат: без должного планирования и понимания моделей опла-
ты облачных сервисов организации могут столкнуться с непредвиденными
затратами. Необходимо иметь четкий план и бюджет для процесса миграции.
• Проблемы производительности: приложения могут работать в облаке с пони-
женной эффективностью из-за различий в архитектуре или непредвиденных
проблем совместимости. После миграции необходимо провести тщательное
тестирование и оптимизацию.
• Недостаток навыков: нехватка опыта работы в облаке может замедлить
процесс миграции и будущую эксплуатацию. Дополнительные затраты на об-
учение (и, возможно, на привлечение специалистов) могут снизить этот риск.
• Проблемы с совместимостью и интеграцией: обеспечить плавную работу
существующих систем и приложений с облачными сервисами может быть
сложно, так как для этого потребуются надежная интеграция и стратегии
тестирования.
• Комплаенс: соблюдать отраслевые нормативные документы и стандарты
в облачной среде может быть сложнее, особенно если организация работает
в жестко регулируемом секторе.
• Привязка к провайдеру: слишком сильная зависимость от технологий
и сервисов конкретного облачного провайдера может создать сложности при
переходе на другого провайдера в будущем, с потенциальными последствиями
для гибкости и экономической эффективности.
Для сокращения рисков, связанных с облачной миграцией, при переносе при-
ложений в облако всегда рекомендуется действовать поэтапно. Чтобы восполь-
зоваться преимуществами экономии, повышения производительности и продук-
тивности ресурсов, сперва определите приоритеты бизнес-функциональности
и оптимизируйте приложения. Начните с миграции, а на последующих этапах
уже можно заняться оптимизацией. Например, если вы проводите миграцию
приложения, использующего базу данных MS SQL, и заменяете его облачно-ори-
ентированной базой данных (такой, как Amazon Aurora или Azure SQL), лучше
Этапы облачной миграции 123
всего на первом этапе провести миграцию приложения, а затем на втором этапе
заняться миграцией базы данных параллельно с мониторингом рисков и ста-
бильности приложения. Оптимизировать приложение на последующих этапах
можно, используя облачно-ориентированный бессерверный технологический
стек — например, AWS Lambda, Amazon API Gateway или Amazon DynamoDB.
Стратегия миграции должна определяться с расчетом на быстрое выполнение,
чтобы команды могли работать независимо. Она может влиять на другие орга-
низационные факторы, например построение инженерной функциональности
в пределах организации вместо передачи на аутсорс. Миграция в облако также
предоставляет отличную возможность для принятия или расширения культуры
DevOps в организации. Эта культура выводит на передний план совместную
работу команд разработки и эксплуатации, оптимизацию рабочих процессов
и повышение эффективности.
©Неожиданные преимущества оптимизации рабочих процессов и укрепления
безопасности часто проявляются во время проверки приложений в ходе
подготовки к миграции.
Облачная миграция включает несколько этапов, которые будут рассмотрены
в следующем разделе.
Этапы облачной миграции
В предыдущем разделе вы узнали о разных стратегиях облачной миграции и, воз-
можно, уже начали группировать свои приложения для применения соответству-
ющих стратегий. Эти стратегии объединяются под общей аббревиатурой 7R (от
их английских названий Retain, Retire, Relocate, Rehost, Repurchase, Replatform
и Refactor), и некоторые из них могут стать частью вашего перехода в облако.
Возможно, вам придется провести миграцию и управлять несколькими прило-
жениями в облаке — для этого желательно создать облачный центр компетенций
(СоЕ, Center of Excellence) и стандартизировать процесс при помощи фабрики
облачной миграции. Облачный СоЕ включает опытных специалистов из ИТ-
и бизнес-команд в пределах организации; они объединяются в специализирован-
ную облачную команду, задача которой — ускорить распространения облачных
знаний в организации. Фабрика облачной миграции определяет миграционные
процессы и инструменты, а также действия, которые необходимо предпринять
в ходе миграции (рис. 3.4).
Как показано на диаграмме, облачная миграция включает следующие этапы.
• Инвентаризация: выявление портфелей облачной миграции и локальных
рабочих нагрузок.
• Анализ: анализ обнаруженных данных и рабочих нагрузок.
• Планирование: разработка стратегии и плана миграции в облако.
124 Глава 3. Миграция на облачные платформы
Рис. 3.4. Этапы облачной миграции
• Проектирование: проектирование приложения в соответствии с выбранной
стратегией.
• Миграция: непосредственное выполнение миграции.
• Интеграция: интеграция с другими приложениями и системными зависи-
мостями.
• Проверка: проверка функциональности после миграции.
• Эксплуатация: организация работы в облаке.
• Оптимизация: оптимизация рабочих нагрузок под облачную инфраструктуру.
Одним из начальных шагов в рамках проекта облачной миграции становятся
оценка и назначение приоритетов приложениям для миграции. Для этого
необходимо провести полную инвентаризацию ИТ-ресурсов среды и опре-
делить, какие серверы, приложения и бизнес-подразделения доступны для
миграции в облако, назначить приоритеты в плане миграции и определить
стратегию миграции для этих приложений. Рассмотрим каждый шаг более
подробно.
Этапы облачной миграции 125
Инвентаризация
На этапе инвентаризации осуществляются выявление и сохранение подробных
данных о портфеле облачной миграции — например, объем проекта миграции.
Определяются необходимые серверы и приложения портфеля, а также их вза-
имные зависимости и текущие эталонные метрики производительности. Кроме
того, при определении рабочей нагрузки необходимо иметь хорошее представ-
ление о следующих параметрах.
• Хранимые данные: идентификация объема и типа хранимых данных (баз
данных, файлов и т. д.). Например: приложение использует 1 Тбайт блокового
хранилища для операций с базой данных.
• Сетевые конфигурации: понимание топологии сети, включая подсети, файр-
воллы и балансировщики нагрузки. Например: приложение распределено по
нескольким подсетям с особыми правилами фильтрации трафика.
• Безопасность и комплаенс: документирование политик безопасности, меха-
низмов защиты данных и требований соответствия. Например: приложение
должно соответствовать требованиям GDPR и использовать шифрование
данных при хранении.
• Частота выпуска релизов: определение частоты развертывания новых ре-
лизов. Например: график выпуска новых релизов приложения — каждые
две недели.
• Модель DevOps: понимание процессов интеграции и развертывания, ис-
пользуемых инструментов и уровня автоматизации. Например: организация
использует Jenkins для CI/CD с высокой степенью автоматизации пайплайна.
• Путь эскалации: документирование процесса для преодоления инцидентов
и сбоев. Например: идентификация ключевых контактов и процедур на случай
прерывания обслуживания.
• Обслуживание ОС и установка обновлений: понимание того, как и когда
применяются обновления ОС. Например: ежемесячная автоматическая
установка обновлений (или ручное обновление).
• Лицензионные требования: определение всех программных лицензий,
нуждающихся в обслуживании или обновлении. Например: проверка того,
использует ли приложение лицензированное промежуточное ПО, которое
необходимо учесть в облаке.
• Другие связанные ресурсы: выявление дополнительных компонентов, свя-
занных с рабочей нагрузкой (внешних зависимостей, сторонних сервисов,
интегрированных инструментов и т. д.). Например, понимание зависимости
приложения от внешнего платежного сервиса.
Подробная информация помогает не только проектировать целевую облачную
среду и определять затраты, но и выявлять любые проблемы в текущем состоя-
нии приложения, которые должны быть исправлены перед миграцией в облако.
126 Глава 3. Миграция на облачные платформы
Процедура определения портфеля идентифицирует все ИТ-ресурсы, задей-
ствованные в проекте облачной миграции, включая серверы и приложения, их
зависимости и метрики производительности.
Также необходимо собрать подробную бизнес-информацию об имеющихся
ресурсах — например, текущее состояние ресурса, цикл обновления при-
ложения, карту приложения и критичность сервера или приложения для
бизнеса. Эти подробности помогут определить стратегию и план миграции.
В большинстве организаций ресурсами занимаются разные бизнес-подраз-
деления и команды. Следовательно, в процессе их определения необходимо
взаимодействовать с разными командами: бизнеса, разработки, дата-центра,
сетей, финансовыми и т. д.
Важно понимать, что ландшафт определения портфеля зависит от различных
факторов.
• Что уже было перенесено в облако?
• Какие существуют зависимости приложения наряду с ресурсами и активами?
• Какие бизнес-факторы направляют процесс облачной миграции?
• Какова оцениваемая продолжительность всего проекта миграции?
• Сколько этапов должен включать процесс миграции?
Одной из главных проблем в проектах миграции становится определение взаи-
мозависимостей между приложениями, особенно связанных с операциями
ввода/вывода (I/O) и коммуникациями. Облачная миграция дополнительно
усложняется расширением организаций из-за слияний, поглощений и роста.
Организации часто не владеют полной информацией, касающейся следующих
параметров:
• количество серверов;
• спецификации серверов (тип и версия ОС, оперативная память, процессор,
диск и т. д.);
• метрики загруженности серверов и метрики производительности;
• зависимости между серверами;
• подробная информация о сети.
Грамотное определение портфеля помогает ответить на следующие вопросы.
• Какие приложения, бизнес-подразделения и дата-центры следует переносить
в облако?
• Насколько хорошо подходят приложения для миграции на облачную плат-
форму?
• Какие известные (и, возможно, неизвестные) риски связаны с миграцией
приложения в облако?
• Какие приоритеты назначить приложениям для миграции?
• От каких других ИТ-ресурсов зависит приложение?
• Каковы наилучшие стратегии миграции для приложения?
Этапы облачной миграции 127
• Что лучше — допустить некоторое время простоя или проводить миграцию
работающего приложения со всеми зависимостями и рисками?
На рынке существуют инструменты, которые помогают автоматизировать
процесс инвентаризации и предоставляют подробную информацию в разных
форматах. Эти инструменты можно классифицировать на основе разных
характеристик: типу развертывания, эксплуатации, поддержке, типу обнару-
живаемых данных. Большинство доступных решений можно разделить на две
общие категории:
• агентские решения, требующие установки программного клиента на сервере
для сбора необходимой информации (например, установки агента монито-
ринга на всех серверах среды для отслеживания метрик производительности,
сбора учетной информации о ПО и системных журналов);
• безагентские решения, которые могут получать эту информацию без уста-
новки дополнительных программ. В качестве примера можно привести
инструменты сетевого сканирования, которые дистанционно проверяют на
серверах открытые порты, работающие сервисы и уязвимости, взаимодействуя
с существующими сетевыми протоколами и управляющими интерфейсами.
Некоторые решения проводят сканирование портов, проверяя серверы или хосты
в поисках открытых портов. Другие выполняют сканирование пакетов, что часто
требует перехвата и анализа сетевых пакетов для декодирования информации.
Эти инструменты также зависят от детализации обнаруженных данных, типов
хранения и информации, включаемой в отчет. Например, некоторые инструменты
могут предоставлять технологический стек более высокого уровня за пределами
сети, а также определять тип выполняемых приложений.
Сложность процесса инвентаризации зависит от рабочей нагрузки организации
и наличия у нее хорошо поддерживаемой системы учета. Этот этап обычно
занимает как минимум две недели, что позволяет собрать более целостную ин-
формацию о среде. Когда вся необходимая информация собрана, ее необходимо
проанализировать. Рассмотрим этап анализа более подробно.
Анализ информации
Анализ необходим, чтобы составить подробное преставление о текущем состоя-
нии ИТ-инфраструктуры и принять обоснованные решения. Анализ помогает
определить, какие приложения и рабочие нагрузки подходят для миграции,
оценить их совместимость с облачными средами и подобрать оптимальные
облачные сервисы и архитектуру. Он также выявляет зависимости между при-
ложениями и инфраструктурой, обеспечивая гладкий переход без прерывания
бизнес-операций. Кроме того, тщательный анализ упрощает прогнозирование
и устранение потенциальных рисков, оптимизацию ресурсов и планирование
затрат, тем самым обеспечивая экономически эффективную и успешную ми-
грацию в облако.
128 Глава 3. Миграция на облачные платформы
Чтобы идентифицировать зависимости серверов и приложений, необходимо
проанализировать данные сетевых подключений, порты, информацию о системе
и процессах на хостах. В зависимости от доступных инструментов вы можете
получить наглядное представление всех обращений с сервера для идентифика-
ции его зависимостей или же выполнить запросы для получения списка всех
серверов, выполняющих конкретный процесс, использующих конкретный порт
или взаимодействующих с конкретным хостом.
Чтобы сгруппировать серверы и приложения для планирования миграции,
необходимо выявить закономерности в конфигурациях хостов. Часто в имена
серверных хостов включаются префиксы, обозначающие их связь с конкретной
рабочей нагрузкой, бизнес-подразделением, приложением или требованием.
В некоторых средах также используются теги и другие метаданные для связы-
вания дополнительной информации с хостом.
Для оптимизации масштабирования целевой среды можно проанализировать
показатели производительности своих серверов и приложений.
• Если серверу выделены избыточные ресурсы, скорректируйте настройки
масштабирования. Этот процесс также можно оптимизировать, обрабатывая
данные реального использования серверов/приложений вместо заявленных
характеристик сервера.
• Если ресурсы сервера недостаточны, назначьте ему более высокий приоритет
для миграции в облако.
Полученную информацию можно объединить с доступностью иных ресурсов
и бизнес-требованиями для назначения приоритетов рабочей нагрузки облач-
ной миграции. Это поможет определить, какое количество серверов включать
в каждый спринт облачной миграции.
После инвентаризации и анализа можно выбрать подходящую стратегию об-
лачной миграции для приложений. Например, для менее сложных серверов
и приложений, работающих на поддерживаемой ОС, может подойти стратегия
lift-and-shift. Серверы или приложения, работающие на неподдерживаемой
ОС, могут потребовать дополнительного анализа для определения подходящей
стратегии.
На следующем этапе проекта миграции выполняется планирование облачной
миграции. Здесь информация, собранная при определении портфеля миграции
и анализе, используется для составления эффективного плана. Рассмотрим
планирование миграции более подробно.
Составление плана миграции
В проекте облачной миграции процессы инвентаризации, анализа и планирова-
ния тесно взаимосвязаны. Сначала полностью определяется портфель миграции,
а затем эти данные анализируются для создания плана миграции. В конце фазы
Этапы облачной миграции 129
анализа на основании анализа и сведений, полученных от владельцев бизнеса,
вы можете выполнить следующие действия для каждого сервера/приложения,
входящего в портфель облачной миграции:
• выбрать стратегию миграции в зависимости от стратегии перехода на облач-
ные технологии, принятой в организации. Вероятно, выбор будет ограничен
фиксированными вариантами (одной из 7R стратегий);
• документировать бизнес-факторы для миграции ресурсов в облако, чтобы
определить необходимость и приоритеты;
• назначить приоритеты для миграции ресурсов в облако. В итоге все ре-
сурсы, входящие в портфель облачной миграции, будут перенесены в об-
лако, но приоритет определит срочность этой миграции. Ресурсы с более
высокими приоритетами можно переместить на первые позиции в очереди
миграции.
На этапе планирования информация, собранная в ходе определения и анализа,
используется для создания волн миграции. Волны представляют собой логиче-
ские группировки ресурсов, которые могут быть последовательно развернуты
в рабочих средах, а также в средах тестирования/разработки, в процессе об-
лачной миграции.
К концу этого этапа проекта миграции создается упорядоченная очередь при-
ложений, которые могут быть перенесены в облако.
Кроме выбора стратегии миграции, этап планирования имеет следующие ос-
новные цели:
• определение критериев успеха миграции;
• определение правильного размера ресурсов в облаке;
• определение приоритета приложений при миграции в облако;
• выявление закономерностей миграции;
• создание подробного плана миграции, чеклиста и графика;
• формирование команд спринтов миграции;
• выбор инструментов для миграции.
®Спринты и очереди задач - концепции методологий непрерывной доставки
Agile и Scrum.
В ходе подготовки к этапу планирования необходимо провести подробное опре-
деление и анализ всех ИТ-активов, входящих в портфель облачной миграции.
Планирование миграции включает выявление структуры учетных записей
в облаке и создание сетевой структуры приложения. Также очень важно по-
нимать гибридные связи с облачной средой назначения. Гибридные связи по-
могут планировать приложения, зависящие от ресурсов, которые продолжают
выполняться локально.
130 Глава 3. Миграция на облачные платформы
Для определения порядка миграции приложений можно использовать три
высокоуровневых шага.
1. Оценить каждое приложение по нескольким измерениям (с точки зрения
как бизнеса, так и технологий), связанным с потенциальной миграцией, для
получения точных количественных оценок среды.
2. Выявить зависимости для каждого приложения и классифицировать их
(фиксированные, сильные связи, слабые связи), чтобы задавать любые тре-
бования к порядку миграции, основанные на зависимостях.
3. Определить правильную стратегию назначения приоритетов, чтобы при-
своить относительные веса разным измерениям.
Если стратегия организации основана на минимизации риска, то больший вес
будет назначен идентификации приложений. Если стратегия основана на про-
стоте миграции, то приложения, которые могут быть мигрированы методом
смены хоста, будут иметь более высокий приоритет, так как рехостинг проще,
чем другие стратегии. Результатом планирования должен быть упорядоченный
список приложений для графика облачной миграции.
Проектирование приложения
На этапе проектирования следует сосредоточиться на успешной миграции
приложений и проверке того, что архитектура приложения удовлетворяет
критериям успеха, определенным на этапе планирования. Также необходимо
следить, чтобы приложение осталось актуальным после перемещения в облако.
Например, если вы храните данные пользовательских сессий на локальном
сервере приложений (чтобы их можно было масштабировать горизонтально),
следует убедиться, что похожая архитектура будет реализована на облачной
платформе после миграции.
На этапе проектирования вы выявляете архитектурный разрыв и дораба-
тываете архитектуру в соответствии с требованиями приложения. Если
в системе используются разные учетные записи, они могут иметь разные
уровни связей или зависимостей; например, учетная запись безопасности
может проверять, что все ресурсы соответствуют правилам безопасности,
принятым в компании.
Продумывая дизайн сети приложения, необходимо учитывать следующие
факторы:
• потоки сетевых пакетов, входящие в приложение;
• маршрутизация внешнего и внутреннего трафика;
• правила файрволов для защиты сети;
• изоляция приложения от интернета и внутренних приложений;
• общее соответствие сетевым стандартам и стандартам управления сетью;
Этапы облачной миграции 131
• сетевые журналы и аудит потока;
• разделение уровней риска приложения в зависимости от уровней взаимо-
действия с данными и пользователями;
• защита и предотвращение DDoS-атак;
• сетевые требования для рабочей и других сред;
• требования доступа для приложений на базе SaaS с совместной арендой;
• сетевые границы на уровне бизнес-подразделений в организации;
• выставление счетов и реализация модели общих сервисов между бизнес -
подразделениями.
В зависимости от потребностей в подключении можно рассмотреть гибридные
варианты с локальной системой.
Чтобы построить и обслуживать безопасную, надежную и экономически
эффективную архитектуру на облачной платформе, необходимо применять
лучшие практики. Перед миграцией проанализируйте, соответствует ли им
ваша облачная архитектура.
При миграции в облако можно спроектировать архитектуру приложения так,
чтобы пользоваться преимуществами глобальной облачной инфраструктуры,
приблизиться к конечному пользователю, снизить риски, улучшить защиту
и выполнить ограничения локализации данных. Системы, которые будут расти
со временем, должны строиться на основе масштабируемых архитектур, кото-
рые могут обеспечить рост пользователей, трафика или данных без ущерба для
производительности.
Часть компонентов архитектуры можно сделать компонентами без сохранения
состояния для приложений, которые должны поддерживать определенную
информацию состояния пользователя. Если какие-либо уровни архитектуры
должны обладать состоянием, для масштабирования упомянутых компонен-
тов вы можете воспользоваться такими методами, как привязка сессий (session
affinity). Для приложений, обрабатывающих огромные объемы данных, при-
меняется метод распределенной обработки.
Другой способ сокращения эксплуатационной сложности выполняемых прило-
жений — использование бессерверной архитектуры. Эта разновидность архитек-
тур сокращает затраты, поскольку с ней не нужно ни платить за недозагруженные
серверы, ни предоставлять избыточную инфраструктуру для реализации высокой
доступности. В главе 5 «Паттерны проектирования облачно-ориентированных
архитектур» вы больше узнаете о бессерверных архитектурах.
На диаграмме (рис. 3.5) показан пример проектирования миграции из локальной
среды в облако AWS. Локальная архитектура выглядит как показано на рисунке.
132 Глава 3. Миграция на облачные платформы
Рис. 3.5. Перенос локальной архитектуры в облако
Представленная архитектура описывает конфигурацию веб-приложения с высо-
кой доступностью, распределенную по нескольким уровням, каждый из которых
выполняет свои задачи по обработке пользовательских запросов. Пользователи
обращаются к приложению по интернету, а запросы равномерно перенаправля-
ются балансировщиками нагрузки по кластеру веб-серверов.
Эти серверы предоставляют фронтенд-контент, а также могут выполнять на-
чальную обработку запросов. Как следствие, более глубокая бизнес-логика
обслуживается отдельным уровнем серверов приложений, которые взаимо-
действуют с базой данных для получения и хранения данных. Для обеспечения
целостности данных поддерживается резервная база данных, готовая вступить
в работу, если у основной базы данных возникнут проблемы.
Многоуровневая архитектура с избыточностью на уровне веб-серверов и сер-
веров приложений, а также стратегией обработки отказов для базы данных
направлена на обеспечение устойчивости при сбоях серверов и оптимальной
производительности даже при высоком трафике.
Этапы облачной миграции 133
Перейдем к проектированию архитектуры для облачной платформы AWS:
Route 53
Зона доступности 2
Зона доступности 1
Балансировщик нагрузки Elastic Load Balancer
Кластер серверов Amazon ЕС2
Кластер серверов Amazon ЕС2
Группа Auto Scaling
Веб-уровень
VPC
Кластер серверов Amazon ЕС2
71
Amazon RDS
R
Группа Auto Scaling
Уровень приложения
R
Кластер серверов Amazon ЕС2
Реплика
экземпляра БД,
предназначенная
для чтения
Уровень базы данных
Реплика
экземпляра БД,
предназначенная
... для .чтения...
Резервный
экземпляр базы
данных
Amazon S3
Amazon
CloudFront
Пользователи
S
Рис. 3.6. Перенос локальной архитектуры в облако
На приведенной диаграмме (рис. 3.6) показаны рехостинг веб-серверов и авто-
масштабирование для обеспечения эластичности, которая необходима, чтобы
справиться с выбросами нагрузки. Также в рамках стратегии облачной мигра-
ции были добавлены эластичные балансировщики нагрузки для распределения
входящего трафика по экземплярам веб-серверов.
Серверы приложений переносились методом рефакторинга, а платформа уровня
базы данных сменилась с традиционной на облачно-ориентированную Amazon
RDS (Amazon Relational Database Service). Вся архитектура распределяется
по нескольким зонам доступности, а база данных реплицируется в резервном
экземпляре во второй зоне для обеспечения высокой доступности.
В завершение этапа проектирования необходимо составить подробный документ
с описанием архитектуры приложения в облаке. Документ должен раскрывать
следующие темы.
• Миграция учетных записей пользователей: учетные записи пользователей,
которые будут перенесены в процессе миграции.
• Конфигурация сети: конфигурация сети, необходимая для приложения
в новой среде.
• Списки контроля доступа: полный список пользователей, групп и приложе-
ний, которым необходим доступ к перенесенным данным.
• Подробная информация о хостинге: где и как будет размещаться приложе-
ние после миграции.
134
Глава 3. Миграция на облачные платформы
• Требования к резервному копированию: стратегии резервного копирования
и специфические требования приложения.
• Потребности лицензирования: любые требования к лицензированию, свя-
занные с приложением.
• Протоколы мониторинга: системы и протоколы мониторинга, которые
должны действовать.
• Меры безопасности: меры безопасности и степень соответствия стандартам,
которые должно соблюдать приложение.
• Обслуживание и обновление: процедуры регулярного обслуживания и гра-
фики обновления.
Создайте дизайн-документ для каждого приложения. Выполните базовые тесты
функциональности на этапе проверки.
Выполнение миграции приложения в облако
Этап непосредственного выполнения миграции воплощает ваши планы в жизнь.
На этом этапе необходимо определить действия и конфигурации, так как вы
будете повторять их в волнах разработки/тестирования и эксплуатации. Прежде
чем выполнять миграцию, убедитесь, что у вас есть план миграции и вы сформи-
ровали команды спринтов, волны и графики миграции, создали приоритетную
очередь задач и оповестили стейкхолдеров о графике и сроках миграции, а также
их ролях и обязанностях.
Вы также должны убедиться, что среда назначения в облаке уже настроена
с фундаментальной архитектурой и основными сервисами. Для конкретных
приложений могут быть отдельные подготовительные этапы — например,
создание резервной копии или синхронизация перед миграцией, отключение
серверов или демонтаж дисков и устройств с сервера. Убедитесь, что все важ-
нейшие компоненты подготовлены — например, сети и правила файрволов,
механизмы аутентификации и авторизации, учетные записи. Все должно быть
настроено как следует. Протестируйте приложения с инфраструктурой, чтобы
убедиться, что они имеют доступ к необходимым серверам, балансировщикам
нагрузки, базам данных, серверам аутентификации и т. д. Обратите внимание
на журналы приложений и мониторинг для измерения производительности
после миграции.
Убедитесь, что в ходе миграции установлено хорошее сетевое подключение с об-
лачной средой. Качественная оценка объема данных, который должен быть пере-
дан в ходе миграции, также поможет оценить время, необходимое для миграции
данных в облако, с учетом таких факторов, как пропускная способность и сетевое
подключение. Также необходимо понимать, какие инструменты доступны для
выполнения миграции. С учетом количества имеющихся устройств на рынке
вам, возможно, придется сузить критерии выбора на основании требований
и других ограничений.
Этапы облачной миграции 135
Как вы уже знаете, рехостинг — зачастую самый быстрый способ миграции при-
ложения в облако. Когда приложение работает на облачной платформе, его можно
дополнительно оптимизировать, чтобы пользоваться всеми преимуществами
облака. Выполняя миграцию приложений в облако методом lift-and-shift, можно
быстрее реализовать преимущества в части затрат и адаптивности.
В зависимости от выбранной стратегии обычно переносят либо весь сервер
вместе с приложением и инфраструктурой, в которой работает приложение,
либо только данные, принадлежащие приложению. Посмотрим, как проводится
миграция данных и серверов.
Миграция данных
Миграцией данных в облако называется процесс перемещения существующих
данных в новое облачное хранилище. Многие приложения требуют хранения
данных в процессе переноса в облако. Миграция хранилища обычно осуществля-
ется одним из двух способов, хотя можно применять оба способа одновременно.
• Lift-and-shift. Может потребоваться до запуска новых приложений в облаке.
• Гибридная модель, ориентированная на облако. Реализуется для новых об-
лачно-ориентированных проектов с унаследованными локальными данны-
ми. Унаследованные хранилища данных могут перемещаться на облачную
платформу позже.
Подход к миграции данных может меняться. Это зависит от таких факторов,
как объем данных, ограничения по структуре сети и пропускной способности,
уровень классификации данных (резервные данные, критические данные,
хранилища данных, архивные данные), уровень безопасности данных и время,
которое можно выделить для проведения миграции.
Представим, что у вас имеются обширные архивы данных или озера данных
и при этом низкая пропускная способность. В таком случае следует переме-
стить данные из их текущего местоположения прямо в дата-центр облачного
провайдера методом lift-and-shift. Это можно сделать, используя выделенные
сетевые подключения для ускорения передачи по сети или физическим пере-
носом данных на жестком диске.
Если хранилища данных можно постепенно переносить со временем или новые
данные собираются из многих необлачных источников, рассмотрите методы,
предоставляющие удобный интерфейс к сервису облачного хранилища. Эти
сервисы миграции могут использовать или дополнять существующие установ-
ки — например, программы резервного копирования/восстановления или сети
хранения данных (SAN, storage area network).
Для небольших баз данных одношаговая миграция является лучшим вариантом.
При этом требуется отключить приложение на небольшое время, от пары часов
до нескольких дней в зависимости от сложности рабочей нагрузки. Во время
простоя вся информация из базы данных извлекается и переносится в облачную
136
Глава 3. Миграция на облачные платформы
базу-приемник. После того как БД пройдет миграцию, ее можно будет сравнить
с исходной БД на предмет возможной потери данных. На этом миграция данных
может считаться завершенной.
В обратной ситуации, если система требует минимального времени простоя, для
баз данных любого размера чаще применяется двухэтапная миграция.
1. Информация извлекается из исходной базы данных.
2. Миграция данных выполняется во время работы базы данных. Вы можете
настроить механизм отслеживания измененных данных (CDC, Change Data
Capture), чтобы убедиться, что все данные прошли миграцию, а приложение
во время миграции продолжало работать.
В этом процессе простоя нет. После завершения миграции можно протестиро-
вать функциональность и производительность при подключении к внешним
приложениям или для любых других критериев.
Так как в это время исходная база данных все еще работает, изменения в ней
необходимо будет распространить или реплицировать, прежде чем отключить
окончательно. В этой точке вы планируете время простоя для базы данных
(обычно несколько часов) и синхронизируете исходную и целевую базы. По-
сле того как все изменения будут перенесены в целевую БД, проверьте данные,
чтобы убедиться в успешности миграции, и перенаправьте трафик приложения
в новую облачную базу.
Возможно, вам придется работать с критически важными базами данных, для ко-
торых недопустимы никакие простои. Проведение миграций с нулевым временем
простоя требует тщательного планирования и соответствующих инструментов
репликации данных. В таких сценариях необходимо использовать средства не-
прерывной репликации данных — такие, как AWS DataSync, Oracle GoldenGate
или NetApp SnapMirror. Важно отметить, что синхронная репликация может
повлиять на задержку исходной базы данных, так как она ожидает, пока данные
будут реплицированы повсюду, прежде чем отправлять ответ приложению.
Если простой базы данных длится лишь несколько минут, можно восполь-
зоваться асинхронной репликацией. Миграция с нулевым временем простоя
предоставляет больше гибкости относительно момента переключения, так как
исходная и целевая базы данных всегда синхронизированы.
Миграция серверов
Существует несколько способов миграции сервера в облако.
• При методе клонирования ОС в исходной системе устанавливается агент,
который клонирует образ операционной системы. Снапшот создается в исход-
ной системе и передается в целевую. Такой тип клонирования используется
для одноразовых миграций.
• При методе копирования ОС все файлы операционной системы копируются
с исходной машины и размещаются в облачном экземпляре. Чтобы метод
Этапы облачной миграции 137
копирования ОС работал эффективно, специалисты и/или инструменты,
выполняющие миграцию, должны хорошо знать нижележащую среду ОС.
• Метод репликации при аварийном восстановлении развертывает в исходной
системе агент, который будет реплицировать данные в целевой системе.
При этом репликация данных происходит на уровне файловой системы или
блоков. Некоторые решения непрерывно реплицируют данные по целевым
томам.
• Копирование дисковых томов полностью осуществляется методом копиро-
вания диска. После копирования всего объема диска его можно загружать
в облако по томам, которые затем присоединять к облачному экземпляру.
• В случае виртуальных машин (VM) можно воспользоваться безагентскими
методами для экспортирования/импортирования VM в облако. Локальный
образ VM копируется методом копирования VM. Если локальные серверы
работают как VM (например, VMware или OpenStack), можно скопировать
образ VM и импортировать его в облако как образ машины. Главное преиму-
щество этого метода — наличие резервных образов сервера, которые могут
запускаться повторно.
• Методом копирования пользовательских данных копируются только пользо-
вательские данные приложения. После экспорта данных с исходного сервера
можно выбрать одну из трех стратегий миграции — повторная покупка, смена
платформы или рефакторинг. Метод копирования пользовательских данных
подходит только для тех, кто знает внутреннее устройство приложения.
С другой стороны, так как он только извлекает пользовательские данные,
этот метод является ОС-независимым.
• Вы можете провести контейнеризацию приложения, а затем заново развер-
нуть его в облаке. Метод контейнеризации копирует как двоичные файлы
приложений, так и пользовательские данные. После копирования двоичных
и пользовательских данных приложение может выполняться в контейнер-
ной исполнительной среде, размещенной в облаке. Так как нижележащая
платформа меняется, это можно рассматривать как пример стратегии плат-
форменной миграции.
На рынке представлены несколько средств миграции, которые помогут про-
вести миграцию данных и/или серверов в облако. Каждый крупный провайдер
публичных облачных платформ предоставляет собственный инструмент мигра-
ции: при этом можно применять другие популярные инструменты миграции —
CloudEndure, NetApp, Dynatrace, Carbonite, OpenText и т. д. Некоторые инстру-
менты используют стратегию аварийного восстановления для миграции, а часть
инструментов аварийного восстановления также поддерживает непрерывную
репликацию для удобства миграций работающих приложений. Некоторые спе-
циализируются на перемещении серверов методом lift-and-shift, миграциях баз
данных между платформами или преобразованиях схем баз данных. Инструмент
должен поддерживать бизнес-процессы, с которыми вам удобно работать и для
управления которыми у вас есть квалифицированные специалисты.
138 Глава 3. Миграция на облачные платформы
Интеграция, проверка и переключение
Миграция, интеграция и проверка неразрывно связаны, так как во время вы-
полнения интеграций с приложением в облаке необходимо проводить непре-
рывную проверку.
Проверка
Для начала следует проверить облачную функциональность, чтобы убедиться,
что приложение выполняется с верной конфигурацией сети (в нужной геолока-
ции) и с желательным уровнем трафика. После завершения проверки базовой об-
лачной функциональности экземпляры можно по мере необходимости запускать
или останавливать. Также желательно проверить, что серверная конфигурация
(объем памяти, процессор, жесткий диск) соответствует ожидаемой.
Для выполнения этих проверок необходимо владеть информацией о приложении
и его функциональности. Когда первичная проверка будет завершена, можно
переходить к интеграционным тестам.
Интеграция
В ходе интеграционных тестов проверяется интеграция с внешними зависимо-
стями и приложениями — например, что приложение успешно подключается
к Active Directory, сервисам CRM, серверам обновлений или управления кон-
фигурацией и общим сервисам. Представим, что приложение должно взаимо-
действовать с сервером Active Directory, сервером управления конфигурацией
или ресурсами общих сервисов, внешними для приложения. Приложению
также может потребоваться интеграция с внешними приложениями, которые
принадлежат вашим клиентам или внешним источникам (например, поставщик
может получать информацию от API приложения после размещения заказа на
покупку).
После завершения процесса интеграции необходимо провести юнит-тесты,
дымовые (smoke) тесты и приемочные тесты (UAT, User Acceptance Test). Ре-
зультаты этих тестов помогут получить одобрение от владельцев приложения
и бизнеса.
На последнем шаге этапа интеграции и проверки выполняется официальное
согласование с владельцами приложения и бизнеса, что позволит перейти к пере-
ключению приложения с локальной среды на облачную.
Переключение
Следующий этап облачной миграции — процесс переключения (cutover). На
этом шаге выполняются необходимые действия для перенаправления трафика
приложения из исходной локальной среды в целевую облачную среду. В зави-
симости от типа данных или типа миграции сервера (одношаговая, двухшаговая
или с нулевым временем простоя) последовательность действий в процессе
Этапы облачной миграции 139
переключения может изменяться. Вот некоторые факторы, которые необходимо
учитывать при определении стратегии переключения:
• приемлемое время простоя для приложения;
• частота обновлений данных;
• особенности обращения к данным (например, данные только для чтения
или статические);
• требования, специфические для приложения (например, синхронизация
с базой данных, резервное копирование, разрешение имен DNS);
• бизнес-ограничения (например, день или время, в которое может произойти
переключение, критичность данных);
• изменение правил управления и согласования.
Живая (live) миграция — самая популярная модель для миграции рабочей на-
грузки, критически важной для бизнеса. Рассмотрим ее подробнее.
Переключение при живой миграции
При этом способе данные непрерывно реплицируются в место назначения,
и большая часть функционального проверочного и интеграционного тестирования
выполняется в месте назначения во время работы приложения. На рис. 3.7 представ-
лена стратегия переключения для живой миграции с нулевым временем простоя.
На диаграмме изображена гибридная облачная архитектура, используемая
с сине-зеленым развертыванием для переключения в режиме живой миграции.
Рис. 3.7. Переключение при живой миграции с использованием
сине-зеленого развертывания
140 Глава 3. Миграция на облачные платформы
©Принцип сине-зеленого развертывания заключается в следующем: в «синей»
среде работает существующая рабочая среда с живым трафиком. Параллельно
предоставляется «зеленая» среда, почти идентичная синей, но использующая
новую версию кода. О сине-зеленом развертывании подробнее пойдет речь
в главе 11 «DevOps и фреймворк архитектуры решений».
Вот как это работает в контексте диаграммы.
1. Текущая конфигурация (синяя среда): локальный дата-центр, находящийся
в Европе (Ирландия), состоит из веб-серверов, серверов приложений и базы
данных. Он обрабатывает определенный процент пользовательского трафика
(20 %, как показано на диаграмме).
2. Целевая конфигурация (зеленая среда): облачная конфигурация AWS
в регионе Северная Вирджиния (США) — новая среда, которая готовится
к обслуживанию всего трафика. Она включает кластер экземпляров Amazon
ЕС2 для парка веб-серверов и другой кластер для парка серверов приложений.
В качестве базы данных используется Amazon RDS.
3. Маршрутизация и распределение трафика: DNS-сервис Amazon Route
53 используется для маршрутизации пользовательского трафика между
локальной и облачной средами AWS. Изначально он настроен на отправку
большей части трафика (80 %) облачной среде AWS, тогда как оставшийся
трафик все еще передается локальному дата-центру.
4. Репликация данных: репликация данных непрерывно выполняется из
локальной базы данных в Amazon RDS из облака AWS, чтобы обеспечить
целостность данных и актуальность информации в облачной среде.
5. Переключение при живой миграции: на этапе переключения при сине-
зеленом развертывании новая (зеленая) среда в AWS становится полностью
работоспособна и обслуживает большую часть трафика.
6. После тщательного тестирования и подтверждения того, что новая среда ра-
ботает стабильно и с ожидаемой производительностью, Route 53 со временем
перемещает весь трафик из локальной (синей) среды в облачную (зеленую).
7. На этом этапе локальная среда остается в резерве. Если в облачной конфигу-
рации AWS возникнут критические проблемы, трафик может быть возвращен
на локальные серверы для обеспечения непрерывности сервиса.
8. Завершение: после того как переключение будет успешно завершено и об-
лачная среда AWS начнет обрабатывать весь трафик, локальная инфра-
структура может быть выведена из эксплуатации или перепрофилирована
для других целей.
Такой подход сводит к минимуму простои и риски, поскольку новая среда
проходит полное тестирование с живым трафиком до того, как прежняя среда
будет выведена из эксплуатации. Он также обеспечивает простой откат, если
при переключении возникнут проблемы.
Этапы облачной миграции 141
На начальной стадии приложение продолжает работать как локально, так
и в облаке, с распределением трафика между двумя этими сторонами. Можно
постепенно повышать долю трафика в облаке, пока весь он не будет передан
новому приложению, что обеспечит переключение без простоя.
Другие часто используемые стратегии переключения подразумевают некоторое
время простоя. Для их реализации необходимо спланировать время простоя при-
ложения, приостановить трафик, перевести приложение в офлайн и провести
последнюю синхронизацию с применением С DC.
После завершающей синхронизации стоит выполнить быстрый дымовой тест,
чтобы убедиться, что все критические функции работают как нужно. В этой точке
можно перенаправить трафик от исходной среды к приложению, работающему
в облаке, таким образом завершая переключение.
Очень важно синхронизировать данные в ходе миграции, так как они
непрерывно изменяются во время работы приложения. Для выполнения
одноразовой миграции данных CDC используются такие средства миграции,
как AWS Database Migration Service (DMS) и Oracle GoldenGate.
Эксплуатация облачного приложения
Этап эксплуатации помогает запускать и использовать приложения в облаке на
уровне, согласованном с бизнес-стейкхолдерами.
Многие организации уже имеют готовые руководства по эксплуатации, опре-
деленные для их локальных сред. Это помогает понять, какие изменения в про-
цессе и какой объем обучения необходимы, чтобы поддерживать цели перехода
на облачные технологии.
Ниже перечислены операции, которые необходимо проводить в облаке:
• установка обновлений на сервере;
• ведение журналов сервисов и приложений;
• облачный мониторинг;
• управление событиями;
• облачные операции безопасности;
• управление конфигурацией;
• управление облачными ресурсами;
• управление изменениями;
• непрерывность деятельности с аварийным восстановлением и высокой до-
ступностью.
Для большинства из этих операций приняты такие стандарты, как ITIL
(Information Technology Infrastructure Library) и ITSM (Information Technology
Service Management). ITSM упорядочивает и описывает действия и процессы
142 Глава 3. Миграция на облачные платформы
планирования, создания, управления и поддержки ИТ-сервисов, тогда как
ITIL применяет лучшие практики для реализации ITSM. Необходимо модер-
низировать принятые в организации практики ITSM, чтобы пользоваться пре-
имуществами адаптивности, безопасности и экономической эффективности,
предоставляемыми облаком.
По завершении миграции в облако ваша работа еще не закончена. Для полного
раскрытия потенциала облака необходима непрерывная оптимизация. Рассмо-
трим эту тему более подробно.
Оптимизация приложений в облаке
Оптимизация — важнейшее условие работы в облаке. По сути, это непрерыв-
ное улучшение. В этом разделе вы узнаете о различных областях оптимизации.
В книге разным факторам оптимизации посвящены целые главы. Ниже пере-
числены основные области оптимизации.
• Производительность: оптимизируйте производительность всего набора
ресурсов (экземпляров, хранилищ, баз данных, доступного пространства
и времени). Вы больше узнаете об архитектурных факторах производитель-
ности в главе 6 «Факторы производительности».
• Безопасность: непрерывно анализируйте и совершенствуйте политики
и процессы безопасности в организации, чтобы защитить данные и ресурсы
в облаке. Архитектурные факторы безопасности более подробно рассматри-
ваются в главе 7 «Факторы безопасности»
• Надежность: оптимизируйте приложения для повышения надежности; это
помогает достичь высокой доступности и определенных пороговых значений
времени простоя для приложений. Тем самым упрощается восстановление
после отказов, обработка возрастающей нагрузки и устранение сбоев с тече-
нием времени. Вы больше узнаете об архитектурных факторах надежности
в главе 8 «Факторы надежности архитектуры».
• Операционное совершенство (operational excellence): оптимизируйте опера-
ционную эффективность и возможность запуска/мониторинга систем в целях
обеспечения ценности для бизнеса и непрерывного улучшения поддержки
процессов и процедур. В главе 9 «Операционное совершенство» вы больше
узнаете об операционных факторах архитектуры.
• Затраты: оптимизируйте экономическую эффективность приложения или
группы приложений с учетом колебаний потребностей в ресурсах. Вы больше
узнаете об экономических факторах архитектуры в главе 10 «Оптимизация
затрат».
Вы должны понимать, какие именно ресурсы в настоящее время развертываются
в вашей облачной среде, и представлять цену каждого из этих ресурсов для оп-
тимизации затрат. Вы можете организовать упреждающее отслеживание затрат
в облаке, используя подробные отчеты тарификации и включение оповещений
тарификации.
Создание гибридной облачной архитектуры 143
Необходимо поддерживать и масштабировать инфраструктуру и меньше платить
по мере выведения большего количества ресурсов. Другой способ оптимизации
затрат основан на проектировании архитектуры с учетом эластичности. Убе-
дитесь, что вы верно определили размеры своих ресурсов, применяете авто-
масштабирование и регулируете потребление в зависимости от цены и потреб-
ности. Например, для приложения может быть выгоднее использовать много
небольших экземпляров, чем меньшее количество более крупных.
Некоторые архитектурные модификации помогут улучшить производитель-
ность приложения. Один из вариантов повышения производительности веб-
серверов — кэширование для ускорения обращений к веб-страницам. Можно
написать приложение, которое позволяет кэшировать графику, JavaScript и даже
целые страницы, чтобы улучшить пользовательский опыт.
Можно спроектировать n-уровневые и сервис-ориентированные архитектуры
для независимого масштабирования каждого уровня и модуля, что также способ-
ствует оптимизации производительности. В главе 4 «Паттерны проектирования
архитектур решений» вы узнаете об этом подробнее.
Возможно, придется сохранить локальную рабочую нагрузку в процессе облачной
миграции. Причиной может быть многоэтапность или невозможность провести
миграцию в облако из-за сложности приложения либо проблем лицензирова-
ния. В таких сценариях необходимо построить гибридное решение, в котором
локальная рабочая нагрузка может взаимодействовать с облачной и легко
обмениваться с ней информацией. В следующем разделе создание гибридных
облачных архитектур рассматривается более подробно.
Создание гибридной облачной архитектуры
Ценность облачных технологий растет, и многие крупные компании перемещают
свою рабочую нагрузку в облако. Тем не менее часто оказывается невозможно
полностью перейти в облако за один день — для большинства клиентов этот
процесс занимает некоторое время. Таким клиентам необходима гибридная
облачная модель, в которой часть приложения, поддерживаемая в локальной
среде, должна взаимодействовать с облачным модулем.
При гибридном развертывании необходимо обеспечить связь между ресур-
сами, выполняемыми в локальной и облачной средах. В самом популярном
варианте гибридное развертывание соединяет облачную и существующую
локальную инфраструктуры в облако для расширения и роста инфраструк-
туры организации с сохранением связи облачных ресурсов с внутренней
системой. Вот некоторые распространенные причины создания гибридных
облачных архитектур.
• Во время рефакторинга и развертывания в облаке по сине-зеленой модели
необходимо сохранить работоспособность старых приложений в локальной
среде.
144
Глава 3. Миграция на облачные платформы
• Старое приложение (например, на мейнфрейме) может не иметь совмести-
мых облачных вариантов и должно продолжать работать в локальной среде.
Лучше всего найти время на рефакторинг технологического стека.
• Часть приложения должна оставаться в локальной среде из-за требований
комплаенса.
• Для ускорения миграции необходимо оставить базу данных в локальной
среде и переместить сервер приложения в облако.
• Необходимо более точно контролировать часть приложения.
• Необходимо извлекать данные в облако из локальной среды для аналитики.
Провайдеры публичных облачных сервисов предоставляют механизм интеграции
существующей инфраструктуры клиента в облако, чтобы клиенты могли легко
использовать его как естественное расширение текущих вложений в инфраструк-
туру. Функциональность гибридных архитектур позволяет клиентам делать все:
от интеграции сетей, безопасности и контроля доступа до автоматизированных
процессов миграции рабочей нагрузки и централизованного управления облаком
с помощью локальных инструментов.
Как видно из рис. 3.8, с помощью AWS Direct Connect можно установить
скоростной канал связи между дата-центром и облаком AWS для реализации
гибридного развертывания с низкой задержкой.
Облако AWS
Зона доступности! J
AWS
Зона доступности 2
Рис. 3.8. Гибридная облачная архитектура (связь локальной среды с облачной)
@На диаграмме VPC-Amazon Virtual Private Cloud, VLAN - виртуальная локальная
сеть (Virtual Local Area Network), VGM - виртуальный частный шлюз (Virtual
Private Gateway), a WAN - глобальная сеть (Wide Area Network).
Создание гибридной облачной архитектуры 145
Как показано на диаграмме, ячейка AWS Direct Connect устанавливает связь
между локальным дата-центром и облаком AWS. Она облегчает выполнение
требований клиента к наличию выделенных оптоволоконных линий с ячейкой
AWS Direct Connect; клиент может заказать такую оптоволоконную линию
у стороннего поставщика (например, AT&T, Verizon, T-Mobile или Comcast
в США). В каждом регионе у AWS присутствует партнерская организация
Direct Connect.
В ячейке AWS Direct Connect оптоволоконная линия соединяется с частной
сетью AWS, которая обеспечивает выделенный сквозной канал связи дата-центра
с облаком AWS. Эти оптоволоконные линии могут обеспечить скорости до
10 Гбайт/с. Для защиты трафика по прямому соединению можно создать VPN
для применения шифрования IPSec к трафику.
Чтобы эффективно сбалансировать риски и преимущества гибридной облачной
модели, необходимо провести комплексную оценку.
Гибридная облачная модель имеет следующие преимущества.
• Гибкость и контроль: гибридные облачные решения предоставляют возмож-
ность использования масштабируемости публичных облачных платформ
с сохранением критических рабочих нагрузок в локальных средах для улуч-
шения контроля и производительности.
• Масштабируемость: компании могут масштабировать свои ИТ-ресурсы по
требованию, чтобы те могли справляться с пиковыми нагрузками без значи-
тельных капитальных вложений в физическую инфраструктуру.
• Улучшенная устойчивость: за счет распределения ресурсов по нескольким
средам гибридная облачная стратегия может улучшить общую устойчивость
системы и обеспечить непрерывность ведения бизнеса.
• Инновации и эксперименты: гибридная облачная модель позволяет органи-
зациям тестировать новые облачные технологии и сервисы без нарушения
работоспособности основных бизнес-приложений, которые остаются в ло-
кальных средах.
Впрочем, наряду с преимуществами есть и риски.
• Сложность: гибридная облачная среда комплексная по своей природе, она
требует сложных функций оркестрации и возможностей сети для гладкого
управления рабочими нагрузками на разных платформах.
• Безопасность: расширение поверхности потенциальных атак (из-за соеди-
нения публичных и частных облаков) требует жестких мер безопасности
и постоянной бдительности.
• Проблемы комплаенса: распределение данных и приложений по разным
облачным средам усложняет соблюдение стандартов.
• Управление затратами: без тщательного планирования и мониторинга расхо-
ды на эксплуатацию гибридного решения могут быстро превысить ожидания
из-за недозагрузки ресурсов или теневых ИТ-ресурсов.
146
Глава 3. Миграция на облачные платформы
Принимая решение о реализации гибридной облачной стратегии, следует срав-
нить эти риски с потенциальными преимуществами, учитывая специфические
потребности организации, необходимую функциональность и стратегические
цели.
С расширением предложения на рынке облачных решений от известных про-
вайдеров организации могут выбрать мультиоблачный подход. Мультиоблачные
стратегии рассматриваются в следующем разделе.
Мультиоблачные решения
Еще до появления облачных технологий организации пользовались продуктами
разных компаний, чтобы иметь доступ к лучшим предложениям в своем классе
и избежать привязки к конкретному поставщику. С появлением на рынке новых
игроков в области публичных облачных платформ у организаций возник интерес
к созданию мультиоблачных решений. Мультиоблачное решение использует
два и более провайдеров публичных облачных платформ для обслуживания
инфраструктурных и технологических потребностей организации. Мульти-
облачная стратегия может сочетать предложения основных провайдеров: AWS,
GCP, Microsoft Azure, Oracle Cloud, IBM и др. Организации могут распределять
свою рабочую нагрузку между облаками в зависимости от географической до-
ступности, технических возможностей и затрат. Они также могут объединять
мультиоблачные решения с локальными.
Ниже перечислены некоторые важные преимущества мультиоблачных стратегий.
• Гибкость в отношении провайдера: в мультиоблачном решении можно вы-
бирать между провайдерами без ущерба для стоимости, гибкости и адаптив-
ности. При нарушении соглашения об уровне обслуживания (SLA, Service-
Level Agreement) можно переключиться на другого облачного провайдера.
• Аварийное восстановление: планирование аварийного восстановления
в том же регионе, поскольку при сбое у одного из провайдеров вы можете
положиться на других. У каждого провайдера облачной платформы есть свои
сильные стороны, и можно выбрать лучшие сервисы, доступные в облаке.
Хотя мультиоблачный подход предоставляет конкурентные преимущества
организациям, у него есть и недостатки.
• Один из самых очевидных — навыки сотрудников. При создании стратегии
хостинга рабочей нагрузки придется найти специалистов по нескольким
облачным технологиям. Более того, команды должны глубоко изучить каж-
дый облачный технологический стек. Подумайте о найме консультанта или
передаче управления облаком на аутсорс интеграторам глобальных систем,
у которых есть соответствующие специалисты.
• Другая серьезная проблема — координация доступности данных, безопасно-
сти и производительности по нескольким облакам. Хотя каждый провайдер
облачных технологий предоставляет встроенные средства безопасности,
Реализация CloudOps 147
кросс-региональные приложения и облачно-ориентированные инструменты
для производительности, ответственность за облако в целом несет органи-
зация. Вам придется реализовать последовательное управление данными
между облаками, получение данных из одного облака и передачу их в другое,
а также обеспечить стабильную производительность.
Таким образом, мультиоблачный подход имеет как преимущества, так и недо-
статки, которые необходимо учитывать при выборе стратегии.
Начав путешествие в мир облачных технологий, вы сможете создавать об-
лачно-ориентированные приложения. Построение облачно-ориентированных
архитектур рассматривается в следующем разделе.
Реализация CloudOps
Модель облачных операций CloudOps представляет собой набор правил и ре-
комендаций, устанавливаемых, отслеживаемых и изменяемых организациями
для управления затратами, повышения эффективности и устранения рисков
облачной инфраструктуры, безопасности и эксплуатации. Эта операционная
модель служит руководством для того, чтобы навыки и действия сотрудников,
процессы и технологии соответствовали облачным задачам, включая безопас-
ность облачных рабочих нагрузок, управление бюджетом и комплаенс.
Важные преимущества модели CloudOps:
• раскрытие потенциала скорости и адаптивности: организации могут ис-
пользовать преимущества гибкости и быстроты отклика, присущие облач-
ным сервисам, ускоряя переход на облачные технологии и модернизацию
приложений как часть цифровой трансформации;
• применение автоматизации для повышения эффективности: автоматизация
уменьшает количество ошибок и вмешательств за счет упрощения рутинных
задач, высвобождая ценные ресурсы и время;
• последовательное управление в масштабе организации: в разных средах
поддерживаются единые облачные механизмы управления, что обеспечивает
стандартизацию и комплаенс в пределах организации;
• эффективное применение навыков сотрудников: CloudOps позволяет специ-
алистам сосредоточиться на достижении бизнес-результатов вместо ручного
выполнения монотонных, однообразных задач;
• сокращение затрат: используя средства автоматизации и управления,
организации могут избежать непредвиденных расходов и оптимизировать
облачные затраты.
Чтобы применять все лучшие облачные практики, компаниям, переходящим
в облако, исключительно важен эффективный менеджмент. Облачные серви-
сы управления обеспечивают более высокую скорость внедрения инноваций
и контроль затрат, комплаенса и безопасности.
148 Глава 3. Миграция на облачные платформы
Автоматизация играет ключевую роль в разработке эффективных моделей облач-
ных операций: облачные ресурсы можно создавать, модифицировать и удалять
автоматически. Концепция облачных сервисов по требованию обеспечивает
гибкость, но на практике многие организации все еще полагаются на ручные
процессы в части выделения, тестирования, определения необходимости и вы-
вода из эксплуатации облачных ресурсов. Ручные рабочие процессы приводят
к повышению трудоемкости, потенциальным ошибкам и росту затрат.
Облачная автоматизация может потребовать некоторых усилий на начальном
этапе, но ее преимущества становятся очевидны, когда даже сложные задачи
начинают выполняться быстро и за несколько кликов. Кроме заметного сокра-
щения объема ручной работы, облачная автоматизация предоставляет и другие
преимущества, в том числе:
• повышение безопасности и устойчивости: автоматизация способствует
повышению безопасности за счет сокращения человеческих ошибок и обес-
печения правильной реализации мер безопасности — например, настройки
учетных данных для новых добавляемых сред разработки. Кроме того, воз-
можно автоматизированное восстановление при возникновении проблем
безопасности, а это повышает устойчивость и предотвращает простои;
• упрощение процессов резервного копирования: автоматизация резервного
копирования обеспечивает непрерывность ведения бизнеса, улучшает дове-
рие клиентов при аварийном восстановлении и минимизирует потери для
бизнеса. Автоматизированное резервное копирование устраняет зависимость
от сотрудников, которые должны запускать этот процесс, что снижает риск
потери данных;
• расширение возможностей управления: автоматизация обеспечивает все-
сторонний мониторинг операций между средами, расширяя возможности
управления за счет отслеживания серверов, баз данных и контроля доступа.
Облачные провайдеры предоставляют широкий спектр сервисов и инструмен-
тов для поддержки современных предприятий в реализации модели CloudOps,
стимулировании инноваций, повышении производительности приложений
и ускорении реакции на обратную связь от клиентов — и все это с сохранением
нужной степени управления и комплаенса.
Модель CloudOps включает несколько основных принципов, относящихся
к разным областям автоматизации рабочей нагрузки IT. Они рассматриваются
в следующем разделе.
Принципы CloudOps
В процессе планирования стратегии CloudOps исключительно важно внедрить
комплексный всесторонний подход. Цель — предоставление облачной среды
и управление ею, с особым вниманием к адаптивности бизнеса и контролю.
Принятие надежной модели CloudOps, не зависящей от пути облачной мигра-
ции, позволяет добиться последовательного контроля и упрощения операций
Реализация CloudOps 149
в разных инфраструктурных средах. Этот стратегический подход позволяет оп-
тимизировать критические ресурсы, что ускоряет поставку бизнес-результатов,
сокращает время выхода на рынок и улучшает безопасность, эффективность
и контроль затрат.
На рис. 3.9 представлены ключевые принципы модели CloudOps, обеспечивающие
комплексную автоматизацию рабочих ИТ-нагрузок.
Рис. 3.9. Ключевые принципы CloudOps
Давайте разберем подробнее фундаментальные принципы CloudOps.
1. Организация управления: создание надежной, грамотно спроектированной
облачной среды с защитными мерами, образующими основу управления.
Следование чек-листу надлежащего проектирования обеспечит всесторон-
ний мониторинг и механизмы оповещения для безопасности, операционное
совершенство, оптимизацию затрат, надежность и производительность.
2. Комплаенс: непрерывный мониторинг соответствия стандартам и мониторинг
конфигураций облачных ресурсов, быстрая обработка отказов автоматизи-
рованными методами и сбор данных аудита для поддержания соблюдения
отраслевых нормативных документов или внутренних политик.
3. Обеспечение и координация: ускоренное предоставление приложений и ре-
сурсов согласно принципам IaC (Infrastructure-as-Code, «инфраструктура
как код») при поддержании целостности и комплаенса в облачной среде.
4. Мониторинг и наблюдение: эффективный сбор метрик и управление прило-
жениями и облачными ресурсами, быстрое выявление и разрешение проблем
для обеспечения оптимальной производительности и надежности.
150 Глава 3. Миграция на облачные платформы
5. Централизация операций: упрощение и автоматизация операций по всему
портфелю приложений, включая бесперебойное выполнение при сохранении
безопасности, защиты и комплаенса.
6. Управление затратами: преобразование бизнес-операций благодаря обес-
печению прозрачности затрат, внедрению мер контроля, прогностических
возможностей и стратегий оптимизации в отношении облачных затрат.
Все принципы подробно рассматриваются в другой нашей книге «AWS for
Solutions Architects: The Definitive Guide to AWS Solutions Architecture for
Migrating to, Building, Scaling, and Succeeding in the Cloud», 2nd Edition.
Итоги
В этой главе мы разобрали фундаментальные принципы архитектуры реше-
ний в публичном облаке. Вы познакомились с облачно-ориентированными
и гибридными архитектурами и получили полное представление об облачных
технологиях и их преимуществах.
В начале главы мы сравнили публичные, частные и гибридные облака. Сравнение
помогает понять разные модели облачного развертывания и соответствующие
им сценарии использования.
Затем концепция публичных облачных платформ была определена более под-
робно через ее архитектуру. Мы также представили некоторых популярных
провайдеров облачных сервисов.
Далее мы перешли к подробному изучению облачно-ориентированной архитек-
туры. Вы получили представление о преимуществах перехода на такую архи-
тектуру, например улучшенной масштабируемости, гибкости и экономической
эффективности.
Разобрав основы публичных облачных платформ, мы перешли к обсуждению
стратегий облачной миграции.
Мы подробно исследовали разные подходы к миграции, включая метод lift-
and-shift, рехостинг, смену платформы, релокацию, рефакторинг, повторное
приобретение, сохранение и удаление. Были приведены рекомендации по вы-
бору наиболее подходящей стратегии облачной миграции в зависимости от
бизнес-требований.
В следующих разделах были описаны основные этапы облачной миграции,
начиная с определения рабочей нагрузки и анализа. Вы узнали, как соста-
вить подробный план миграции и спроектировать приложения для гладкой
миграции в облако. Также мы рассмотрели важные вопросы миграции при-
ложения, включая миграцию данных, миграцию серверов, интеграцию, про-
верку и переключение. Мы представили методы оптимизации приложений
в облаке, обеспечивающие оптимальную производительность и экономическую
эффективность.
Дополнительные источники 151
Так как организации часто имеют дело со сложными инфраструктурами, мы
поговорили о том, как создать гибридную облачную архитектуру и использовать
мультиоблачные решения, чтобы пользоваться всеми преимуществами разных
облачных провайдеров.
Глава завершилась обсуждением того, как проектировать облачно-ориентиро-
ванные архитектуры. Особое внимание было уделено принципам CloudOps,
помогающим в практической реализации облачной рабочей нагрузки.
В следующей главе рассматриваются паттерны проектирования архитектур
и основные архитектуры — многоуровневые, сервис-ориентированные, бессер-
верные и микросервисные.
Дополнительные источники
За дополнительной информацией об основных провайдерах облачных платформ
обращайтесь по следующим ссылкам.
• Amazon Web Services (https://aws.amazon.com):
Сурабх Шривастава (Saurabh Shrivastava), Ниланджали Шривастав
(Neelanjali Srivastav), Альберто Артасанчез (Alberto Artasanchez) и Имтияз
Сайед (Imtiaz Sayed) «AWS for Solutions Architects»: https://www.amazon.
com/gp/product/180323895X;
AWS Well-Architected Framework: https://aws.amazon.com/architecture/
well-architected/;
• Google Cloud Platform (https://cloud.google.com):
GCP Cloud Architecture Framework: https://cloud.google.com/architecture/
framework;
• Microsoft Azure (https://azure.microsoft.com):
Azure Well-Architected: https://azure.microsoft.com/en-us/solutions/cloud-
enablement/well-architected#reliability;
• Oracle Cloud Infrastructure (OCI): https://www.oracle.com/cloud/;
• Alibaba Cloud: https://us.alibabacloud.com;
• IBM Cloud: https://www.ibm.com/cloud.
Почти каждый облачный провайдер предоставляет новым пользователям воз-
можности для освоения своих продуктов. Вы можете зарегистрироваться со
своим адресом электронной почты и опробовать их предложения, прежде чем
остановить выбор на одном из них.
ГЛАВА 4
ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
АРХИТЕКТУР РЕШЕНИЙ
Вы когда-нибудь задумывались над тем, как большие компании проектируют
масштабируемые системы? Прежде чем браться за разработку приложений,
архитекторы решений прорабатывают и сравнивают разные варианты, чтобы
спроектировать архитектуру, соответствующую бизнес-потребностям.
Существует много способов проектирования. Архитектор решений должен
выбрать наиболее подходящий в зависимости от пользовательских требова-
ний и архитектурных ограничений в отношении затрат, производительности,
масштабируемости и доступности. В этой главе будут представлены различные
паттерны архитектуры решений, основные (эталонные) архитектуры и их при-
менение в реальных сценариях.
В предыдущих главах вы узнали о принципах проектирования архитектуры
решений. Материал этой главы интересен и важен, так как вы сможете при-
менить свои знания к разным паттернам проектирования архитектур. В этой
главе мы разберем некоторые популярные паттерны архитектур решений:
многоуровневые, управляемые событиями, микросервисные, слабосвязанные,
сервис-ориентированные и RESTful-архитектуры.
Вы узнаете о преимуществах разных архитектурных стилей и рассмотрите
примеры, демонстрирующие их применение. Кроме того, вы научитесь видеть
некоторые антипаттерны проектирования наряду со следующими паттернами.
В этой главе мы рассмотрим следующие вопросы.
• Построение n-уровневой архитектуры.
• Создание мультитенантной архитектуры на базе SaaS.
• Понимание сервис-ориентированной архитектуры.
• RESTful-архитектура веб-сервисов.
• Построение архитектур на базе кэша.
• Паттерн МVС (Model-View-Controller, модель — представление — контроллер).
• Построение архитектур, управляемых предметной областью (DDD).
• Паттерн «Предохранитель» (Circuit Breaker).
• Паттерн «Переборка» (Bulkhead).
• Паттерн «Плавающий IP» (floating IP).
Паттерны проектирования архитектур решений 153
• Развертывание приложения в контейнере.
• Работа с базами данных в архитектуре приложений.
• Чистая архитектура.
• Уход от антипаттернов в архитектурах решений.
К концу главы вы будете знать, как оптимизировать архитектуру решения
и применять лучшие практики. Можно сказать, что эта глава станет смысловым
центром, самой важной частью вашего обучения.
Построение л-уровневой архитектуры
В n-уровневой архитектуре (также называемой многоуровневой архитектурой)
применяются принципы и атрибуты слабосвязанных архитектур, а также мас-
штабируемости и эластичности. Функции продукта делятся на уровни (пред-
ставления, бизнеса, баз данных, сервисов), чтобы каждый уровень можно было
реализовать и масштабировать независимо от других (рис. 4.1).
N-уровневая архитектура упрощает внедрение новых технологий и разработ-
ку. Она также обеспечивает гибкость добавления новой функциональности
на каждом уровне без последствий для функциональности других уровней.
В контексте безопасности каждый уровень может поддерживаться безопасным
и изолированным от других, так что, если один уровень будет скомпромети-
рован, это не отразится на других. Многоуровневая архитектура также об-
легчает диагностику и управление приложениями, так как позволяет быстро
определить источник проблем и ту часть приложения, в которой необходимо
провести диагностику.
Route S3
Amazon S3
Зона доступности 1
Зона доступности 2
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Кластер серверов Amazon ЕС2
R
Уровень базы данных
Amazon RDS
Amazon
CloudFront
Реплика
экземпляра БД,
предназначенная
для чтения
Реплика
; экземпляра БД,
предназначенная
для чтения
Резервный
экземпляр базы
данных
Рис. 4.1. Трехуровневая архитектура веб-сайта
Кластер серверов Amazon ЕС2
Балансировщик нагрузки Elastic Load Balancer
DynamoDB NoSQL Store
Веб-уровень Scaling
Группа Auto Scaling
Уровень приложен
154
Глава 4. Паттерны проектирования архитектур решений
Самая распространенная многоуровневая архитектура — трехуровневая,
и о ней стоит поговорить подробнее. На рис. 4.1 представлен пример архи-
тектуры AWS, которая обеспечивает взаимодействие с веб-приложением
из браузера и выполнение необходимых действий — например, купить в ин-
тернет-магазине футболку или прочитать блог и оставить комментарий.
Представленная архитектура состоит из трех уровней.
• Веб-уровень: часть приложения, обращенная к пользователю. Конечные
пользователи взаимодействуют с веб-уровнем для сбора или предоставления
информации.
• Уровень приложения: состоит в основном из бизнес-логики и действует на
основании информации, полученной с веб-уровня.
• Уровень базы данных: на этом уровне хранятся все виды пользовательских
данных и данных приложения.
Рассмотрим эти уровни более подробно.
Веб-уровень
Также называется уровнем представления (presentation tier). Веб-уровень
предоставляет пользовательский интерфейс, который помогает конечному
пользователю взаимодействовать с приложением. Веб-уровень содержит поль-
зовательский интерфейс (в данном случае страницу веб-сайта), где пользователь
вводит информацию или просматривает ее. Веб-разработчик может заранее
построить пользовательский интерфейс уровня представления с использова-
нием таких технологий, как HTML, CSS, Angular, React, JavaServer Pages (JSP)
и Active Server Pages (ASP). Этот уровень собирает информацию, полученную
от пользователя, и передает ее уровню приложения.
Веб-уровень обращен к пользователю, и компании большую часть времени зани-
маются улучшением пользовательского опыта (UX, User experience). Во многих
организациях существуют специальные UX-команды, которые проводят иссле-
дования, чтобы понять, как пользователи взаимодействуют с приложениями.
Архитектор решений должен убедиться, что архитектура включает входные дан-
ные UX и данные о производительности загрузки страниц. Поток информации
должен беспрепятственно проходить между веб-уровнем и уровнем приложе-
ния, чтобы приложение возвращало пользователям верные данные в пределах
ожидаемого времени (логина, загрузки профиля и т. д.).
Перейдем к уровню приложения.
Уровень приложения
Также называется уровнем логики (logic tier), так как именно здесь разме-
щается вся бизнес-логика. Уровень представления получает информацию от
пользователя и передает ее уровню логики, который обрабатывает ее и получает
Паттерны проектирования архитектур решений 155
результат. Например, на сайте интернет-магазина (скажем, Amazon) пользовате-
ли указывают интервал дат, чтобы вывести сводку заказов за соответствующий
период. Веб-уровень передает информацию (интервал дат) уровню приложения.
Уровень приложения обрабатывает ее для выполнения бизнес-логики (подсчет
количества заказов, общей стоимости и количества приобретенных товаров).
Далее он возвращает информацию веб-уровню, чтобы тот отобразил ее для
пользователя.
Как правило, в трехуровневой архитектуре все алгоритмы и сложная логика раз-
мещаются на уровне приложения, включая создание рекомендательной системы
или отображение персонализированных страниц для пользователя на основе его
истории просмотра. К этим уровням можно добавить и другие: уровень пред-
метной области, или домена, уровень доступа к данным и другие для создания
четырех- или пятиуровневой архитектуры. Разработчики могут реализовать
уровень приложения на языке программирования для сервера — например, C++,
Java, .NET или Node.js. Уровень приложения находится в центре системной ар-
хитектуры, и на него приходится основная работа по проектированию. Многие
функции приложения зависят от логики, построенной на уровне приложения.
Уровень приложения выполняет логику, используя данные, хранящиеся на
уровне базы данных. Рассмотрим уровень базы данных более подробно.
Уровень базы данных
Уровень базы данных, также называемый уровнем данных (data tier), хранит
всю информацию, относящуюся к пользовательским профилям и транзакциям.
Фактически он содержит все данные, предназначенные для долговременного
хранения. Эта информация передается уровню приложения для обработки,
а затем в итоге отображается для пользователя на веб-уровне. Представим, что
пользователь зашел на сайт с идентификатором и паролем. Уровень приложения
сверяет учетные данные пользователя с информацией, хранящейся в базе данных.
Если введенные данные совпадают с хранящимися, пользователю разрешается
войти в приложение и обратиться к авторизованной части сайта.
Для построения уровня данных архитектор может выбрать реляционные БД,
например PostgreSQL, MariaDB, Oracle Database, MySQL, Microsoft SQL Server,
Amazon Aurora или Amazon RDS. Архитектор также может добавить базу дан-
ных NoSQL — например Amazon DynamoDB, MongoDB или Apache Cassandra.
Уровень данных используется для хранения информации о транзакциях, пользо-
вательских сессиях и конфигурации приложения. Архитектор может рассмотреть
возможность добавления кэширующих баз данных (таких как Memcached или
Redis) для обеспечения необходимой производительности. О базах данных под-
робнее речь пойдет в главе 12 «Инженерия данных для архитектур решений».
Уровень данных требует особого внимания в отношении безопасности. Необ-
ходимо защитить пользовательскую информацию, применяя шифрование при
156
Глава 4. Паттерны проектирования архитектур решений
хранении и при передаче. На диаграмме n-уровневой архитектуры можно заме-
тить, что каждый уровень имеет собственную настройку автомасштабирования
и, следовательно, может масштабироваться независимо. Кроме того, у каждого
уровня есть сетевая граница; это означает, что доступ к одному уровню не обе-
спечивает доступа к другим. Вопросы безопасности подробно рассматриваются
в главе 7 «Факторы безопасности».
Архитектор должен выбрать количество уровней в зависимости от сложности
приложения и требований пользователя. Например, можно добавить допол-
нительные уровни (скажем, уровень доступа к данным для логики обращений
к БД) и оставить уровень хранения данных для ядра БД. Можно добавить до-
полнительные уровни для снижения сложности за счет логического разделения,
которое повышает общее удобство обслуживания приложения, а также способ-
ность к масштабированию и обеспечению производительности.
Создание мультитенантной архитектуры
на базе SaaS
В предыдущем разделе вы узнали о многоуровневой архитектуре, которая при
построении для отдельной организации также называется выделенной (single
tenant). В настоящее время все большую популярность приобретает мульти-
тенантная (multi-tenant) архитектура, поскольку организации приветствуют
цифровую революцию с сохранением низких затрат на приложение и эксплуа-
тационных затрат.
Модель SaaS (Software-as-a-Service) строится на базе мультитенантной архитек-
туры, где экземпляр программного продукта и сопутствующая инфраструктура
предназначаются для нескольких клиентов. Клиенты используют приложение
и базу данных совместно. Арендаторы (tenants) изолируются на основании
своих уникальных конфигураций, профилей и данных и остаются невидимыми
друг для друга во время совместного использования одного и того же продукта.
Поставщики SaaS-решений с мультитенантной архитектурой отвечают за веё, от
аппаратного уровня до программного. Они освобождают организации от необходи-
мости поддержки и обновления продуктов, так как берут на себя эту обязанность.
Каждая организация — покупатель продуктов SaaS выступает арендатором.
Арендаторы могут настраивать пользовательский интерфейс на уровне конфи-
гурации без изменения кода. Так как несколько клиентов совместно используют
общую инфраструктуру, они выигрывают от масштаба, что еще больше снижает
затраты. Самые популярные поставщики SaaS — Salesforce CRM, Jira Software,
Slack, Google Workspace и Amazon Connect.
Как видно из рис. 4.2, две организации-арендатора используют общие про-
граммные продукты и инфраструктуру. Поставщик SaaS предоставляет доступ
к уровню решений, для чего выделяет уникальный идентификатор (ID) арен-
датора каждой организации.
Создание мультитенантной архитектуры на базе SaaS
157
На приведенной архитектурной диаграмме показано, что уровень представления
предоставляет пользовательский интерфейс, а уровень приложения используется
для хранения бизнес-логики. На уровне доступа к данным у каждого арендатора
изоляция базы данных обеспечивается одним из следующих способов.
• Изоляция на уровне базы данных: в этой модели каждый арендатор свя-
зывается со своим ID базы данных. Когда арендаторы запрашивают данные
из пользовательского интерфейса, каждый перенаправляется к своей базе
данных. Эта модель необходима, если клиенты не могут пользоваться общей
базой данных из соображений комплаенса и безопасности.
• Изоляция на уровне таблиц: этот уровень изоляции достигается выделени-
ем отдельной таблицы каждому арендатору. В этой модели таблица должна
однозначно связываться с арендатором, для чего ей назначается префикс с ID
пользователя. Когда арендатор запрашивает данные из пользовательского
интерфейса, запрос перенаправляется к таблице с его уникальным ID.
• Изоляция на уровне строк: на этом уровне изоляции все арендаторы со-
вместно используют одну таблицу базы данных. В таблице присутствует
дополнительный столбец, в котором хранится уникальный ID арендатора
для каждой строки данных. Когда отдельный арендатор хочет обратиться
к своим данным из пользовательского интерфейса, уровень доступа к данным
формулирует запрос к общей таблице, включающий ID арендатора. Каждый
арендатор получает строку, которая относится только к их пользователям.
Если подписка на сервис нужна многим пользователям, важно найти предложе-
ние, подходящее по соотношению цены и качества. Выбирая между покупкой или
созданием, необходимо проводить сравнение затрат с учетом общей стоимости
владения. Для большинства организаций создание программных продуктов
158 Глава 4. Паттерны проектирования архитектур решений
не является основной специализацией. Модель SaaS набирает популярность еще
и потому, что она позволяет организациям сосредоточиться на своей профильной
деятельности и предоставить решение ИТ-вопросов техническим экспертам.
Для корпоративных клиентов необходимо провести тщательный анализ, чтобы
понять, подойдет ли им решение SaaS в зависимости от их специфических
требований к функциональности. Дело в том, что возможности настройки
модели SaaS часто ограниченны.
Выбор механизма изоляции определяется факторами, зависящими от тре-
бований комплаенса и безопасности в организации, затратами и условиями,
относящимися к заключению контрактов арендаторами.
Сервис-ориентированная архитектура (SOA, Service-Oriented Architecture) —
популярный метод проектирования и построения приложений, особенно если
требования организаций уникальные и специфические. SOA более подробно
рассматривается в следующем разделе.
Сервис-ориентированная архитектура
В паттернах SO А разные компоненты приложений взаимодействуют по сети
с использованием коммуникационного протокола. Каждый сервис предостав-
ляет сквозную функциональность (например, получение истории заказов).
Архитектура SO А широко применяется в больших системах для интеграции
бизнес-процессов — например, выделения платежного сервиса из основного
приложения и размещения его в отдельном решении.
Коротко говоря, архитектуры SO А берут монолитные приложения и выделяют
некоторые операции в отдельные сервисы, работающие независимо. Целью SOA
становится ослабление связей с сервисами приложения. Иногда SOA включает
отделение сервисов друг от друга и выделение ресурсов в дополнительные эк-
земпляры этого сервиса. Например, в то время как некоторые компании пред-
почитают хранить свои данные в одной БД, разбитой по таблицам, архитектор
SOA обратится к возможности модуляризации приложения по функциям
в разные базы данных. Это позволяет масштабировать пропускную способность
и управлять ею на основании индивидуальных потребностей таблиц каждой
базы данных.
SOA предоставляет ряд преимуществ — например, параллелизацию разработки,
развертывания и эксплуатации. Эта архитектура ослабляет связи между серви-
сами, чтобы оптимизировать и масштабировать каждый сервис по отдельности.
С другой стороны, она также требует более надежного управления, чтобы работа,
выполняемая командами разных сервисов, соответствовала одному стандарту.
С применением SOA решение может стать достаточно сложным, и затраты
на поддержку этой сложности заметно возрастут, так что следует тщательно
Сервис-ориентированная архитектура 159
выбирать инструменты и автоматизировать мониторинг, развертывание и мас-
штабирование сервисов.
Есть несколько вариантов реализации SO А.
Когда-то протокол SOAP (Simple Object Access Protocol) был самым популярным
протоколом передачи сообщений, но он слишком тяжел, так как обмен данными
осуществляется полностью в XML. Архитектура REST (Representational State
Transfer) становится более популярной, так как разработчикам нужно строить
более легкие мобильные и веб-приложения. На момент написания книги архи-
тектура SOAP считается устаревшей, так что в этом издании мы сосредоточимся
на архитектуре REST.
RESTful-архитектура
RESTful (REST-совместимый) веб-сервис обеспечивает более высокую произ-
водительность благодаря своей облегченной архитектуре. Он допускает разные
форматы передачи сообщений (JSON, простой текст, HTML, XML), в отличие
от архитектуры SOAP, которая поддерживает только XML. REST — архитек-
турный стиль, определяющий стандарт проектирования приложений со слабой
связанностью, использующий протокол HTTP для передачи данных.
JSON QavaScript Object Notation) — более доступный формат для обмена данны-
ми в архитектуре REST, упрощенный и не привязанный к конкретному языку.
В нем используются простые пары «ключ — значение», которые обеспечивают
его совместимость со структурами данных, определяемыми в большинстве
языков программирования.
Веб-сервисы RESTful формируют архитектурный фреймворк с особыми прави-
лами проектирования веб-сервисов. Они нацелены на обеспечение совместимо-
сти между разными компьютерными системами, соединенными по интернету.
С веб-сервисами RESTful системы могут взаимодействовать через обращение
к текстовым данным и их изменение, используя согласованный и заранее
определенный набор операций, не зависящих от прошлых взаимодействий
или состояний. Рассмотрим некоторые фундаментальные принципы RESTful-
архитектуры веб-сервисов с их наглядным представлением на примере сайта
интернет-магазина.
• Отсутствие состояния (stateless): каждый запрос от клиента к серверу
должен содержать всю информацию, необходимую серверу для понимания
и обработки запроса. Каждый запрос, выдаваемый клиентом, включает всю
необходимую информацию для выполнения, и хранить на сервере какую-
либо информацию, относящуюся к сессии, не нужно: все управление такой
информацией осуществляется полностью на стороне клиента. В примере
с интернет-магазином каждый запрос от клиента (например, просмотр товара
или добавление его в корзину) должен содержать всю информацию, необхо-
димую для обработки. Если пользователь захочет просмотреть содержимое
своей корзины, запрос должен включать идентификатор этой корзины или
160 Глава 4. Паттерны проектирования архитектур решений
другую информацию, чтобы сервер мог найти запрошенные данные и вернуть
их в ответе.
• Архитектура «клиент — сервер»: в этой архитектуре выделяются две разные
части, клиент и сервер, взаимодействующие друг с другом по сети. Клиент
отвечает за управление пользовательским интерфейсом и взаимодействие
с пользователем, а сервер — за бэкенд и обработку данных. Они могут
развиваться по отдельности, не влияя друг на друга. Клиент (браузер или
приложение) управляет взаимодействиями с пользователем (например,
выбором товаров), а сервер обеспечивает выборку данных, управление кор-
зиной и оформление заказов. Взаимодействие между ними осуществляется
посредством запросов и ответов HTTP.
• Однородный интерфейс: REST использует однородный интерфейс, упроща-
ющий архитектуру и ослабляющий связи в ней. В RESTful API для взаимо-
действий используется набор стандартных методов HTTP, соответствующих
операциям CRUD (Create, Read, Update, Delete), то есть создание, чтение,
обновление, удаление:
GET: метод используется для получения данных с сервера. Например,
когда пользователь хочет просмотреть список товаров на сайте example,
com, его браузер отправляет серверу запрос GET. URL-адрес может иметь
вид https://example.com/api/products, а сервер отвечает списком товаров
в структурированном формате (например, J SON или XML);
POST: метод используется для создания нового ресурса на сервере. Предста-
вим, что пользователь хочет добавить новый товар в свою корзину на сайте
example.com. Он может заполнить форму с описанием товара и щелкнуть
кнопку Add to Cart (Добавить в корзину). Это действие инициирует запрос
POST к URL https://example.com/api/cart, при этом подробная информация
о товаре включается в тело запроса. Затем сервер обрабатывает данные
и добавляет новый товар в корзину пользователя;
PUT: метод используется для обновления существующего ресурса на
сервере. Если пользователь хочет обновить количество единиц товара
в своей корзине, запрос PUT отправляется по специальному URL вида
https://example.com/api/cart/{productld}. Тело запроса включает обновленное
количество, а сервер обновляет соответствующую позицию в корзине
пользователя;
DELETE: метод используется для удаления ресурса с сервера. Например,
если пользователь хочет удалить товар из своей корзины, его браузер от-
правляет запрос delete к URL вида https://example.com/api/cart/{productld}.
Сервер удаляет указанный товар из корзины.
• Ограничиваясь этими стандартными методами, API предоставляют раз-
работчикам согласованный механизм взаимодействия с веб-сервисами. Это
позволяет разработчикам выполнять основные операции с ресурсами, при
этом им не нужно понимать подробности реализации.
Создание сайта интернет-магазина на базе RESTful-архитектуры
161
• Ресурсы: в REST все считается ресурсом, и конкретные URL могут обращать-
ся к любым ресурсам. Ресурсы являются ключевыми абстракциями в REST,
и ресурс может представлять один объект или набор объектов. Такие ресурсы,
как товары, пользователи, заказы и позиции корзины, идентифицируются
URL-адресами. Например, для обращения к конкретному товару может ис-
пользоваться URL вида www.amazon.com/products/fproduct_id}.
• Представление ресурсов: ресурсы могут иметь разные представления:
JSON, XML, HTML и т. д. Клиенты взаимодействуют с ресурсами, получая
их представления и выполняя операции с этими представлениями. Когда
клиент хранит представление ресурса, у него достаточно информации для
модификации ресурса на сервере. Один и тот же ресурс товара может по-
разному отображаться в веб-браузере и в мобильном приложении.
• Многоуровневая система: архитектура позволяет вводить промежуточные
уровни (например, балансировщиков нагрузки или кэширования) без влия-
ния на то, как клиент взаимодействует с сервером. Каждый уровень может
предоставлять конкретную функциональность, что улучшает масштабирова-
ние и обслуживаемость системы. Сайт интернет-магазина может содержать
разные уровни: балансировщиков нагрузки, кэширования, аутентификации
и т. д. Клиенту знать об этих уровнях необязательно. Запрос на просмотр
товара может пройти через уровень кэширования для ускорения ответа,
причем клиент об этом ничего не будет знать.
• Код по требованию: серверы могут предоставлять клиенту исполняемый
код для выполнения в контексте клиента. Это позволяет переместить часть
логики приложения на сторону клиента. Сайт интернет-магазина может от-
править клиентскому браузеру код JavaScript для выполнения определенной
функциональности (например, проверки на стороне клиента или улучшения
интерактивности при просмотре страницы клиентом).
Архитектурный стиль RESTful использует стандартные методы HTTP. Со-
блюдение этих принципов позволяет веб-сервисам RESTful быть простыми,
масштабируемыми и удобными в обслуживании. Многие современные веб-API
разрабатывались с соблюдением принципов RESTful и использованием стан-
дартных соглашений для выполнения операций CRUD с ресурсами.
Давайте рассмотрим пример RESTful-архитектуры.
Создание сайта интернет-магазина
на базе RESTful-архитектуры
Некоторые интернет-магазины (например, www.amazon.com) имеют пользо-
вателей со всего мира и огромный каталог с миллионами товаров. С каждым
товаром хранятся его изображения, а также отзывы и видеоролики. Поддержка
такого обширного каталога для глобальной пользовательской базы — весьма
непростая задача.
162 Глава 4. Паттерны проектирования архитектур решений
Представленная ниже архитектура AWS (рис. 4.3) следует принципам RESTful.
Сервисы работают максимально независимо друг от друга.
Рис. 4.3. RESTful-архитектура интернет-магазина
На этой диаграмме можно отметить несколько особенностей.
• Когда пользователь вводит адрес сайта в браузере, его запрос направляется
серверу DNS для загрузки сайта. Запросы DNS маршрутизируются сервисом
Amazon Route 53 к серверу, на котором размещаются веб-приложения.
• Пользовательская база является глобальной. Далее пользователи обычно
просматривают товары, так как на сайте представлен обширный каталог
со статическими изображениями и видеороликами. Сеть распространения
контента (в данном случае Amazon Cloud Front) кэширует и поставляет ста-
тические ресурсы пользователям.
• Содержимое каталога (в частности, статические изображения товаров
и видеоролики), а также другие данные приложения (например, файлы
журналов) хранятся в Amazon S3.
• Пользователи могут просматривать сайт с нескольких устройств; например,
добавить товары в корзину с мобильного устройства, а оплатить покупку
с настольного компьютера. Для поддержки пользовательских сессий требу-
ется долгосрочное хранилище сессионных данных — такое, как DynamoDВ.
Dynamo D В представляет собой базу данных No SQL, для которой не нужна
фиксированная схема, поэтому данный вариант отлично подходит для ка-
талогов товаров и атрибутов.
Создание сайта интернет-магазина на базе RESTful-архитектуры
163
• Amazon ElastiCache используется как уровень кэширования товаров, чтобы
сократить количество операций чтения из базы данных и записи в нее, обес-
печить высокую производительность и сократить задержку.
• Удобные средства поиска чрезвычайно важны для продаж и успеха бизнеса.
Amazon CloudSearch помогает построить масштабируемую функциональ-
ность поиска за счет загрузки каталога товаров из DynamoDB. Также можно
воспользоваться Amazon Kendra для создания поисковой системы с под-
держкой ИИ.
• Рекомендации, основанные на истории просмотра и покупок, могут стимули-
ровать пользователя к приобретению дополнительных товаров. Отдельный
рекомендательный сервис может потреблять данные журналов, хранящиеся
в Amazon S3, и предоставлять пользователю рекомендации для возможных
покупок.
• Приложение интернет-магазина также может иметь множественные уровни
и компоненты, требующие частоты развертывания. AWS Elastic Beanstalk
осуществляет автоматическое выделение инфраструктуры, развертывание
приложения, обрабатывает нагрузку за счет применения автомасштабиро-
вания и проводит мониторинг приложения.
В этом разделе вы познакомились с архитектурой RESTful. В следующем раз-
деле рассматривается важная тема — архитектура на базе кэша.
Построение архитектуры на базе кэша
Кэшированием называется временное хранение данных или файлов в про-
межуточном хранилище, расположенном между источником запроса и долго-
срочным хранилищем. Эта практика направлена на ускорение будущих запро-
сов и сокращение нагрузки на канал связи. Кэширование повышает скорость
работы приложений и снижает затраты. Оно позволяет повторно использовать
ранее загруженные данные. Для повышения производительности приложения
кэширование может применяться на разных уровнях архитектуры: веб-уровне,
уровне приложения, уровне данных и сетевом уровне.
В общем случае для поддержки кэширования приложений используются опе-
ративная память (RAM) и системы кэширования в памяти. Если кэширование
связано с локальным сервером, кэш не сохранит данные в случае его сбоя.
Многие приложения работают в распределенной среде, так что лучше создать
выделенный уровень кэширования, не зависящий от жизненного цикла при-
ложения. При применении к приложению горизонтального масштабирования
все серверы должны иметь возможность обращаться к центральному уровню
кэширования для достижения наилучшей производительности.
На рис. 4.4 изображен механизм кэширования на разных уровнях архитектуры
решения.
164
Глава 4. Паттерны проектирования архитектур решений
Сторона клиента
(мобильного
и десктопного)
Быстрое получение контента веб-сайтов
с использованием заголовков кэширования HTTP и браузеров
Уровни архитектуры решения
Интернет
(система доменных
имен — DNS)
Веб-контент
(веб-уровень)
Приложение
(уровень
приложения)
Быстрое преобразование домена в IP-адрес
с помощью DNS-сервера
Быстрое получение контента с веб-серверов и управление веб-сессиями
на стороне сервера
Улучшение производительности приложения и ускорение обращения
к данным с использованием хранилищ данных «ключ-значение»
и локальных кэшей
База данных
(уровень БД)
Сокращение задержки, связанной с запросами к базе данных,
при помощи буферов баз данных и хранилищ
данных «ключ-значение»
Рис. 4.4. Кэширование на разных уровнях архитектуры
Как показано на диаграмме, на каждом уровне архитектуры используется свой
механизм кэширования.
• Кэширование на стороне клиента: применяется с мобильными устройствами
и десктопными компьютерами. Этот механизм кэширует ранее просмотрен-
ный веб-контент, чтобы быстрее реагировать на последующие запросы. Каж-
дый браузер имеет собственный механизм кэширования. Кэширование HTTP
ускоряет приложение за счет кэширования контента в локальном браузере.
Заголовок HTTP cache-control описывает политики кэширования браузе-
ра для клиентских запросов и ответов сервера. Эти политики определяют,
где должен кэшироваться контент и сколько времени он должен храниться;
Создание сайта интернет-магазина на базе RESTful-архитектуры
165
этот параметр называется «сроком жизни», или TTL (Time То Live). Фай-
лы cookie — еще один метод хранения информации на машине клиента для
ускорения ответа браузеру.
• Интернет-кэш DNS: когда пользователь вводит адрес сайта в интернете,
публичный сервер DNS проводит сопоставление IP-адреса. Кэширование
этой информации снижает время загрузки сайтов. Информация DNS может
кэшироваться на локальном сервере или браузере после первого запроса,
и все последующие запросы к этому сайту будут ускоряться.
• Кэширование веб-контента: многие запросы включают загрузку веб-контента:
графики, видео, страниц HTML. Кэширование этих ресурсов поблизости
от местоположения пользователя может значительно ускорить ответ при
загрузке страницы. Оно также снижает время чтения данных и загрузки
сервера. CDN (сеть доставки контента) представляет собой сеть погранич-
ных локаций (edge locations), в которых может кэшироваться статический
контент (графика, видео). Это особенно полезно при чтении тяжеловесных
приложений: игр, блогов, страниц каталогов товаров и т. д. Пользовательская
сессия содержит большой объем информации, связанной с предпочтениями
пользователя и его текущим состоянием. Чтобы улучшить взаимодействие
с пользователями, данные сессии хранятся в специальном хранилище пар
«ключ — значение» для ускорения ответов.
• Кэширование уровня приложений: на уровне приложения кэширование
может применяться для хранения результата сложных повторяющихся
запросов, чтобы избежать многократного выполнения бизнес-логики
и обращений к базе данных. В целом этот подход улучшает произво-
дительность приложения, сокращая нагрузку на базу данных и инфра-
структуру.
• Кэширование базы данных: производительность приложения сильно
зависит от скорости и пропускной способности, обеспечиваемых базой
данных. Кэширование базы данных значительно повышает ее пропускную
способность и снижает задержку выборки данных. Кэш базы данных может
устанавливаться перед любой реляционной или нереляционной БД. Неко-
торые поставщики БД реализуют интегрированное кэширование, тогда как
приложения обеспечивают локальное кэширование.
Redis и Memcached — самые популярные системы кэширования. Хотя
Memcached работает быстрее (система подходит для низкоструктурированных
данных и организует их хранение в формате «ключ-значение»), Redis — более
устойчивая система кэширования, способная работать со сложными структурами
данных, необходимых для приложения; тема более подробно рассматривается
в разделе «Memcached и Redis» этой главы.
Рассмотрим некоторые распространенные паттерны кэширования.
166
Глава 4. Паттерны проектирования архитектур решений
Паттерн Cashe distribution (Распределенное
кэширование) в трехуровневой веб-архитектуре
Традиционная архитектура веб-хостинга следует популярной трехуровневой
модели веб-приложений, в которой архитектура делится на уровни представ-
ления, приложения и хранения данных.
Как показано на архитектурной диаграмме AWS на рис. 4.5, кэширование при-
меняется на веб-уровне, уровне приложения и уровне баз данных.
Рис. 4.5. Архитектура паттерна «Распределенное кэширование»
Паттерны кэширования необходимо использовать с целью свести к минимуму
количество обращений к базе данных. Чтобы повысить качество взаимодействия
с пользователями, можно написать приложение, в котором кэшируются изо-
бражения, JavaScript и даже целые страницы. На приведенной выше диаграмме
кэширование реализуется между разными уровнями архитектуры.
• Amazon Route 53 используется для кэширования соответствий между DNS
и IP, упрощая управление доменами.
• Amazon S3 служит хранилищем статического контента, включая графику
высокого разрешения и видеоролики.
• Amazon CloudFront предоставляет кэширование на границе сети для контента
с высоким трафиком, используя заголовки с ас he-control для определения
частоты обновления по источнику.
• Amazon DynamoDB используется для сессионных хранилищ, что позволяет
веб-приложениям управлять пользовательскими сессиями посредством
кэширования.
Создание сайта интернет-магазина на базе RESTful-архитектуры
167
• Механизм балансировки нагрузки Elastic Load Balancing равномерно рас-
пределяет трафик между группами Auto Scaling веб-серверов.
• Amazon ElastiCache предоставляет сервисы кэширования приложениям,
фактически сокращая нагрузку на уровень базы данных.
Обычно кэшируется статический контент, но в некоторых сценариях кэширова-
ние динамического или уникального контента может улучшить производитель-
ность приложения. Решение зависит от конкретных паттернов использования
и потребностей.
Рассмотрим один из таких паттернов.
Паттерн Rename distribution (Распределение
с переименованием)
При работе с CDN (например, Amazon CloudFront) часто используемые дан-
ные хранятся в пограничных локациях рядом с пользователем для повышения
производительности. Обычно в CDN устанавливается срок жизни (TTL) для
данных, это означает, что пограничная локация не будет обращаться к серверу
с запросом обновленных данных, пока TTL не истечет. Напомним, что TTL
определяет время хранения объекта в системе кэширования, прежде чем он
будет удален или обновлен. Возможны сценарии, в которых требуется обновить
кэшированный контент CDN немедленно — например, если нужно исправить
ошибочное описание товара.
В такой ситуации нельзя ожидать истечения TTL. Паттерн «Распределение
с переименованием» позволяет обновить кэш сразу после публикации новых
изменений, чтобы пользователь мог немедленно получить обновленную инфор-
мацию. На рис. 4.6 показано применение этого паттерна с AWS.
Как видно из диаграммы, использование паттерна «Распределение с переимено-
ванием» совместно с паттерном «Распределение кэширования» помогает решить
проблему с обновлением. При использовании этого паттерна вместо того, чтобы
переписать файл на сервере-источнике и ожидать истечения TTL в Cloudfront,
сервер отправляет обновленный файл с новым именем, после чего обновляет
веб-страницу новым URL. Когда пользователь запрашивает исходный контент,
CloudFront приходится загружать его из источника (вместо предоставления
устаревшего файла, уже находящегося в кэше).
Впрочем, старый файл можно инвалидировать сразу же, но это будет дорого
стоить, поэтому лучше поместить новую версию файла в CDN, чтобы начать
ее использовать немедленно. Чтобы загружался новый файл, придется снова
обновить URL в приложении, что добавляет затрат по сравнению с вариантом
инвалидации кэша. Решение следует выбирать в зависимости от бизнес-требо-
ваний и бюджета.
168 Глава 4. Паттерны проектирования архитектур решений
3. Cloud Front получает обновленную
версию с сервера-источника
Облако AWS
Amazon CloudFront
Ячейка Amazon S3
1. Новые данные размещаются
с новым именем файла
2. Страница распространяется
с обновленным URL
Веб-приложение
Рис. 4.6. Архитектура паттерна «Распределение с переименованием»
Если пользовательская база имеет широкое географическое распределение
и вы не хотите использовать CDN, можно воспользоваться кэширующим
прокси-сервером. Этот вариант более подробно рассматривается в следующем
разделе.
Паттерн Cache proxy (Кэширующий прокси-сервер)
Добавление уровня кэширования может значительно повысить производитель-
ность приложения. В паттерне «Кэширующий прокси-сервер» статический
или динамический контент кэшируется выше уровня сервера веб-приложения.
На рис. 4.7 показано, что уровень кэширования помещается перед кластером
веб-приложения.
На этой диаграмме для обеспечения высокопроизводительной поставки данных
содержимое кэша поставляется кэширующим сервером.
Некоторые преимущества паттерна «Кэширующий прокси-сервер»:
• он обеспечивает поставку контента с использованием кэша, не требуя из-
менений на уровне веб-сервера или сервера приложения;
• он снижает нагрузку на генерирование динамического контента;
• кэш можно организовать на уровне браузера: кэшировать заголовки HTTP,
URL, cookie и т. д. Также можно кэшировать информацию на уровне кэша,
если вы не хотите хранить ее на уровне браузера.
При использовании паттерна «Кэширующий прокси-сервер» приходится под-
держивать несколько копий кэша, чтобы избежать появления единой точки
отказа. В некоторых случаях статический контент должен поставляться как
с сервера, так и из CDN. Эта гибридная ситуация рассматривается в следую-
щем разделе.
Создание сайта интернет-магазина на базе RESTful-архитектуры
169
Веб-приложение Веб-приложение Веб-приложение
Рис. 4.7. Архитектура паттерна «Кэширующий прокси-сервер»
Паттерн Rewrite proxy
(Заменяющий прокси-сервер)
Иногда бывает нужно изменить ссылки для обращений к статическому контенту
веб-сайта (например, графике и видео) без изменения существующих систем. Для
этого можно выделить прокси-сервер с использованием паттерна «Заменяющий
прокси-сервер». Чтобы перевести обращения к статическому контенту на другое
хранилище (например, сервис контента или интернет-хранилище), установите
прокси-сервер перед парком веб-серверов.
На рис. 4.8 прокси-сервер установлен перед уровнем приложения, что позволяет
изменить местоположение поставки контента без изменения самого приложения.
Как показано на диаграмме, прокси-сервер, реализующий паттерн, размещается
перед работающей системой. Для создания прокси-сервера можно воспользо-
ваться такими продуктами, как Apache или NGINX.
Ниже представлена последовательность действий для построения паттерна
«Заменяющий прокси-сервер» с использованием AWS, как в примере.
1. Разместите в экземпляре ЕС2 работающий прокси-сервер, который может
перезаписывать контент между балансировщиком нагрузки и сервисом
хранения (например, Amazon S3), в котором хранится статический контент.
170 Глава 4. Паттерны проектирования архитектур решений
2. Добавьте правила прокси-сервера для перезаписи URL в контенте. Эти
правила помогут ELB (Elastic Load Balancing) обратиться к новому место-
нахождению, как на рис. 4.8, где правило прокси-сервера перенаправляется
с https://cdn/test.jpg на /test.jpg. ELB — предоставляемый AWS сервис, ко-
торый автоматически распределяет входящий трафик приложения между
несколькими целями (например, серверами Amazon ЕС2, контейнерами
и IP-адресами).
3. Примените автомасштабирование к прокси-серверам, настроив минимальное
и максимальное количество прокси-серверов в соответствии с нагрузкой
приложения.
В этом разделе вы узнали, как реализовать кэширование для распределения
статического контента в сети. Однако в улучшении производительности при-
ложения важную роль играет кэширование на уровне приложения. Посмотрим,
как паттерн кэширования приложения применяется для управления произво-
дительностью доставки динамических пользовательских данных.
Рис. 4.8. Архитектура паттерна «Заменяющий прокси-сервер»
Создание сайта интернет-магазина на базе RESTful-архитектуры
171
Паттерн Арр caching
(Кэширование на уровне приложения)
Для реализации кэширования в приложениях необходимо добавить уровень
кэширования между серверами приложений и базой данных. Паттерн «Кэши-
рование на уровне приложения» позволяет сократить нагрузку на базу данных,
так как самые частые запросы будут обслуживаться с уровня кэширования.
Этот паттерн повышает общую производительность приложений и баз данных.
Как показано на рис. 4.9, уровень кэширования добавляется между уровнем
приложения и уровнем базы данных в AWS.
Балансировщик нагрузки Elastic Load Balancer
Группа Auto Scaling
Парк серверов приложения^
Сервер приложения запра-
шивает данные у механизма
кэширования, и если данные
отсутствуют в кэше, они за-
гружаются из базы данных
Уровень
кэширования
I Amazon RDS
Механизм кэширования
загружает данные в кэш
и обслуживает запрос из
кэшированных данных
к
Уровень кэширования перед базой
данных сокращает количество об-
ращений к ней, что повышает общую
производительность приложения
Рис. 4.9. Архитектура паттерна «Кэширование на уровне приложения»
При обращениях к данным может использоваться либо отложенное кэширо-
вание (lazy caching), либо кэширование со сквозной записью (write-through).
В первом случае механизм кэширования проверяет, находятся ли данные в кэше,
и если нет — загружает их из базы данных и сохраняет в кэше для обслуживания
будущих запросов. Отложенное кэширование также называется кэшированием
на стороне (cache aside). При кэшировании со сквозной записью данные запи-
сываются в кэш и хранилище данных одновременно. Если данные в кэше будут
потеряны, их можно снова получить из базы данных.
Выбирайте отложенное кэширование, если вы используете приложение с интен-
сивным чтением, а кэширование со сквозной записью — при операциях, требую-
щих немедленной согласованности данных. Например, отложенное кэширование
может использоваться для каталога товаров на сайте интернет-магазина, где
172 Глава 4. Паттерны проектирования архитектур решений
подробные описания товаров часто читаются, но обновляются намного реже.
Когда пользователь обращается к описанию товара, отсутствующему в кэше, оно
загружается из базы данных и сохраняется в кэше для последующих обращений,
что сокращает нагрузку на базу данных. Кэширование со сквозной записью
может использоваться для раздела отзывов пользователей на сайте интернет-
магазина, где написанные пользователями отзывы мгновенно отображаются на
странице товара. Когда пользователь отправляет свой отзыв, он записывается
в кэш и базу данных одновременно, гарантируя, что все последующие запросы
чтения получат самые актуальные данные.
В следующем разделе рассматриваются популярные системы кэширования
Redis и Memcached.
Memcached и Redis
Memcached и Redis — две популярные системы кэширования, используемые
при разработке приложений. Redis часто применяется для более сложных
требований — например, создания таблицы лидеров игры. Со своей стороны,
Memcached более производителен и позволяет справляться с более серьезными
нагрузками приложений.
У каждой системы кэширования имеются сильные и слабые стороны. Рассмо-
трим наиболее существенные различия между ними — это поможет вам принять
решение о том, какую из них использовать (табл. 4.1).
Таблица 4J, Сравнение Memcached и Redis
Memcached Redis
Поддерживает многопоточность Однопоточное выполнение
Может использовать дополнительные ядра процессора для ускорения выпол- нения Не может использовать многоядерный процессор, из-за чего работает относи- тельно медленно
Поддерживает данные в стиле «ключ — значение» Поддерживает сложные и продвинутые структуры данных
Долгосрочное хранение данных не под- держивается; данные, хранящиеся в па- мяти кэша, теряются в случае сбоя Возможно долгосрочное хранение дан- ных, для чего используются встроенные реплики для чтения с механизмом об- работки отказов
Прост в обслуживании Обслуживание усложняется необходи- мостью поддержки кластера
Хорошо подходит для кэширования не- структурированных строковых данных: неструктурированных страниц HTML, сериализованной разметки JSON и т. д. Хорошо подойдет для создания кэша таблицы лидеров игры, приложения для голосования в реальном времени и т. д.
Архитектура MVC (Model-View-Controller) 173
Если вам нужно решить, какую систему использовать, выберите сценарий,
который оправдает использование Redis или Memcached. Memcached проще
и требует меньших затрат на обслуживание; обычно эту систему выбирают,
когда кэшу не нужна расширенная функциональность, которую предоставляет
Redis. С другой стороны, Redis лучше подойдет, если требуется долгосрочное
хранение данных, работа со сложными типами данных или любые другие из
перечисленных возможностей.
При реализации кэширования важно учитывать актуальность кэшируемых дан-
ных. При высокой частоте попаданий в кэш (cashe hit) запрашиваемые данные
часто находятся в кэше. Сокращение числа прямых обращений снижает нагрузку
на базу данных и повышает общую производительность приложения. Промах
кэша (cashe miss) происходит, когда запрашиваемые данные отсутствуют в кэше,
что повышает нагрузку на базу данных. Объем кэша ограничен, так что следует
установить TTL и вытеснять старые данные из кэша в соответствии с потреб-
ностями приложения.
Как было показано в этом разделе, применение кэша имеет ряд преимуществ,
включая повышение производительности, обеспечение прогнозируемой произ-
водительности и сокращение затрат при работе с базой данных.
В следующем разделе представлена архитектура на базе приложения, демон-
стрирующая принцип слабой связанности и работы с ограничениями, — МVС.
Архитектура MVC (Model-View-Controller)
MVC — один из самых популярных паттернов проектирования, встречающихся
при разработке приложений. В этой архитектуре приложение разделяется на три
взаимосвязанных компонента: модель (Model), представление (View) и контрол-
лер (Controller). Такое деление улучшает модульность разработки, упрощает
тестирование и обслуживание. Рассмотрим эти компоненты по отдельности.
• Модель: представляет внутреннее состояние приложения вместе с правилами,
логикой и данными, которые управляют состоянием. Модель не зависит от
представления или контроллера; это означает, что изменения в пользователь-
ском интерфейсе или бизнес-логике не влияют на работу с данными. Таким
образом обеспечивается согласованность данных между разными частями
приложения. К обязанностям модели относятся:
управление данными: модель содержит всю логику, относящуюся к дан-
ным. Независимо от того, получены ли данные из базы данных или API,
модель обработает их;
реализация бизнес-правил: модель реализует бизнес-логику (например,
вычисления или преобразования данных);
уведомление об изменениях: модель уведомляет связанные с ней пред-
ставления и контроллеры об изменениях данных, чтобы те могли обно-
виться соответствующим образом.
174 Глава 4. Паттерны проектирования архитектур решений
• Представление: визуальное представление данных модели. Оно точно опреде-
ляет, как данные приложения отображаются для пользователя. Представление
автоматически обновляется при изменении нижележащих данных модели;
это гарантирует, что пользователь всегда видит самые актуальные данные.
На базе одних данных модели можно создать несколько представлений
в разных форматах (таблицы, диаграммы, детализированные представления).
К обязанностям представления относятся:
отображение данных: получает данные из модели и представляет их
в понятном формате;
обслуживание пользовательского интерфейса (UI): обрабатывает всю
UI-логику приложения (поля ввода, кнопки и т. д.).
• Контроллер: контроллер является посредником между моделью и представ-
лением. Он получает пользовательский ввод от представления, обрабатывает
его (возможно, с обновлением модели) и возвращает результат представле-
нию. Контроллер следит за тем, чтобы представление и модель всегда были
синхронизированы друг с другом. Он становится централизованным обработ-
чиком всех пользовательских взаимодействий, что делает управление этими
взаимодействиями более систематичным и организованным. К обязанностям
контроллера относятся:
обработка пользовательского ввода: получает и интерпретирует команды
пользователя, преобразуя их в действия, выполняемые моделью;
обновление модели: изменяет данные в модели, отправляя ей команды;
обновление представления: изменяет информацию, отображаемую пред-
ставлением, на основании пользовательского ввода и изменений модели.
Основные преимущества паттерна МVС:
• разделение ответственности: изолируя данные приложения, пользова-
тельский интерфейс и логику управления, MVC способствует модульной
разработке;
• возможность повторного использования: компоненты могут повторно ис-
пользоваться разными частями приложения и даже разными приложениями;
• удобство обслуживания: паттерн значительно упрощает обновление, тести-
рование и отладку разных частей приложения;
• гибкость: позволяет разработчикам менять одну часть системы, не влияя на
другие (например, изменить пользовательский интерфейс без изменения
обработки данных).
MVC — мощный архитектурный паттерн, который обеспечивает надежное
управление данными, пользовательским интерфейсом и бизнес-логикой. Он
широко используется в разных средах разработки приложений, от фреймворков
веб-разработки до десктопных приложений, для создания масштабируемых
и простых в обслуживании программ.
Архитектура MVC (Model-View-Controller) 175
Следуя принципам MV С, архитекторы приложений могут создавать структу-
рированные, эффективные и гибкие приложения, более простые в обновлении
и обслуживании. Лучше понять МVС поможет пример.
Применение MVC при проектировании книжного
интернет-магазина
При проектировании интернет-магазина архитектура MVC эффективно об-
рабатывает сложные взаимодействия между данными книг, пользовательским
интерфейсом и пользовательским вводом, что обеспечивает повышенную
стабильность и масштабируемость системы. Рассмотрим каждый компонент
более подробно.
• Модель: управление данными, относящимися к книгам, авторам, категориям,
отзывам клиентов и т. д. Несколько примеров операций модели:
получение подробной информации о конкретной книге;
обновление складских запасов после покупки;
добавление новой книги в каталог.
• Представление: вывод информации для пользователя в удобном и интерак-
тивном формате. Примеры представлений:
страница со списком книг: выводит список книг с названиями, обложками
и ценами;
страница с подробным описанием книги: выводит подробную информацию
о конкретной книге: автор, описание, отзывы и т. д.;
страница покупательской корзины: позволяет пользователям просматри-
вать, добавлять и удалять отдельные позиции из корзины.
• Контроллер: обрабатывает пользовательские взаимодействия, обновляет
модель по мере необходимости и представление для отражения изменений.
Примеры действий контроллера:
поиск книги: пользователь вводит условие поиска. Контроллер выдает
запрос к модели для поиска книг и обновляет представление для ото-
бражения результатов;
добавление в корзину: пользователь щелкает кнопку Add to Cart (Добавить
в корзину); контроллер обновляет модель, чтобы отразить появление
нового товара в корзине; представление обновляется для вывода нового
состояния корзины;
оформление заказа: пользователь решает оформить заказ. Контроллер
обрабатывает транзакцию, обновляет модель (включая складские запасы)
и активирует представление с подтверждением.
Паттерн МVС обеспечивает четкое разделение ответственности, упрощая рас-
ширение, обслуживание и тестирование приложений.
176 Глава 4. Паттерны проектирования архитектур решений
Предметно-ориентированное проектирование
Предметно-ориентированное проектирование (DDD, Domain-Driven Design) —
методология и набор практик, направленных на понимание и решение проблем
сложности в программных продуктах. Этот подход используется для проектиро-
вания и моделирования программ на основании предметной области (domain),
то есть базовой логики и ключевых концепций бизнеса. За счет использования
единой терминологии и разделения системы на четкие контексты DDD способ-
ствует глубокому пониманию пространства задачи и приводит к формированию
решения, точно отражающего фундаментальные потребности бизнеса. Мето-
дология DDD особенно полезна в сложных предметных областях, в которых
крайне важно приблизить программу к концепциям реального мира, которые
она представляет.
Рассмотрим DDD на конкретном примере одной предметной области: системы
управления здравоохранением. Представьте, что вы разрабатываете систему для
управления историями болезни, посещениями врачей, курсами лечения, счетами
пациентов и т. д. для медицинской организации. Применение концепций DDD
к этой предметной области могло бы выглядеть так.
• Предметная область: термином «предметная область» обозначается конкрет-
ная совокупность проблем, которые призван решить программный продукт.
Логика приложения строится на основе области знаний и действий. По-
нимание предметной области исключительно важно для создания системы,
действительно удовлетворяющей потребности бизнеса. Для медицинской
организации предметной областью будет управление здравоохранением,
при этом основное внимание будет уделяться пациентам, медицинскому
персоналу, приемам врачей, курсам лечения и выставлению счетов.
• Единый язык: общий язык, совместно используемый разработчиками и не-
техническими стейкхолдерами для описания предметной области. Единый
язык нужен для того, чтобы все участники команды одинаково понимали
основные термины и концепции — это снижает риск путаницы и обеспечивает
четкое взаимопонимание с использованием терминов, понятных как профес-
сиональным медикам, так и разработчикам: «пациент», «прием», «лечение»,
«медицинский работник» и т. д.
• Ограниченные контексты: в методологии DDD приложение делится на ограни-
ченные контексты, каждый из которых представляет конкретную обязанность
или функциональность в общей предметной области. Ограниченный контекст
включает все понятия, определения и логику для этой конкретной части пред-
метной области и явно определяет, что находится внутри, а что снаружи его
границ. Например, ограниченный контекст управления пациентами включает
управление данными пациентов, личной информацией, медицинской историей
и т.д. Ограниченный контекст планирования приемов включает управление
приемами, планирование, отмену, перенос записи и т. д., а ограниченный кон-
текст выставления счетов включает обработку платежей, страховку, счета и т. д.
Архитектура MVC (Model-View-Controller) 177
• Сущности: эти объекты обладают четкой идентичностью, которая перемеща-
ется по времени и разным состояниям — например, пациенты (с уникальными
идентификаторами) или медицинский персонал (с уникальными учетными
данными).
• Объекты-значения: объекты, описывающие характеристики чего-либо, но не
имеющие индивидуальности. Объекты-значения неизменяемы (immutable)
и могут легко замещаться. Примеры — адрес, дата рождения, история болезни
(все эти объекты не имеют индивидуальной идентификации).
• Агрегаты: совокупности взаимосвязанных объектов, которые рассматри-
ваются как единое целое для изменений в данных. В агрегате присутствует
корневая сущность, а внешние ссылки ограничиваются этим корнем для
обеспечения целостности. Например, в онлайн-системе управления здравоох-
ранением прием у врача может быть смоделирован как агрегат. Агрегат может
включать сущности и объекты-значения: пациенты (которым назначен при-
ем), медицинские работники (которые будут принимать пациента), кабинеты
(где проходит прием), интервал времени (на которые запланирован прием).
В данном случае сущность «прием» становится корнем агрегата. Любые из-
менения в категориях «пациент», «медицинский работник», «кабинет» или
«интервал времени» будут осуществляться через сущность «прием». Тем
самым гарантируется, что агрегат «прием» сохранит последовательность
и обеспечит соблюдение всех бизнес-правил, относящихся к приемам врачей.
• Репозитории: используются для получения агрегатов с нижележащего уров-
ня хранения данных. Они предоставляют абстракцию, которая позволяет
остальным компонентам приложения взаимодействовать с хранилищем
данных способом, соответствующим модели предметной области. Например,
репозиторий «пациент» используется для получения и управления сущ-
ностями «пациент», а репозиторий «прием» — для получения и сохранения
агрегатов «прием».
• Фабрики: фабрики отвечают за инкапсуляцию логики создания сложных
объектов и агрегатов. Они обеспечивают создание объектов или агрегатов
в последовательном и действительном состоянии. Например, фабрика «паци-
ент» используется для создания новой сущности «пациент» с действительным
исходным состоянием, а фабрика «прием» — для создания нового агрегата
«прием» с необходимой информацией.
• Сервисы: если операция логически не принадлежит объекту-значению или
сущности, она может быть определена как сервис. Сервисы являются частью
модели предметной области и содержат бизнес-логику, оперирующую кон-
цепциями предметной области. Например, в контексте «выставление счетов»
сервис выставления счетов содержит такие операции, как вычисление общей
суммы, применение страховочных скидок, формирование счетов и т. д.
• События предметной области: события предметной области отражают тот
факт, что в предметной области произошло нечто значительное. Они могут
инициировать другие действия в системе или других системах. Например,
178 Глава 4. Паттерны проектирования архитектур решений
событие планирования приема, инициируемое при планировании нового
приема, может оповещать соответствующих медицинских работников, а по-
сле успешной оплаты может происходить событие завершения проведения
платежа, которое может инициировать процесс формирования чека.
• Уровень защиты от повреждений (anti-corruption layer, ACL): на нем выпол-
няются преобразования между разными частями системы, использующими
разные языки или модели. Он обеспечивает поддержание целостности каж-
дой модели и обработку несоответствий. Если система выставления счетов
должна взаимодействовать с внешним сторонним платежным шлюзом,
защитный уровень может выполнять преобразование между моделью пред-
метной области в контексте выставления счетов и моделью, используемой
внешней системой.
В системе управления здравоохранением DDD обеспечивает тщательное мо-
делирование и структурирование сложной логики предметной области. Эта
модель способствует совместной работе специалистов сферы здравоохранения
(экспертов предметной области) и разработчиков ПО для создания единого
понимания и языка.
Архитектура системы приближена к реальным операциям здравоохранения
за счет определения четких ограниченных контекстов, сущностей, агрегатов
и других концепций DDD. Такое соответствие гарантирует, что программный
продукт предоставит надежное и гибкое решение, адаптированное для специ-
фических потребностей этой предметной области.
Рассмотренный пример показывает, как DDD может стать важным инструментом
для создания сложных, хорошо структурированных систем. DDD фокусируется
на соответствующей предметной области и упрощает взаимодействие между
различными стейкхолдерами.
Обработка зависимостей — важная часть работы в сложных системах. По-
смотрим, как обработать зависимость между разными сервисами с помощью
паттерна «Предохранитель», чтобы ошибка в одном сервисе не привела к потере
работоспособности всей системы.
Паттерн Circuit Breaker («Предохранитель»)
В распределенной системе часто отправляются вызовы к нижележащим серви-
сам, и в ходе вызова может произойти сбой, или сервис может зависнуть вместо
возвращения ответа. Зачастую код многократно повторяет попытки неудачного
вызова. Сложность заключается в том, что исправление удаленного сервиса спо-
собно занять минуты или даже часы, а немедленная повторная попытка может
привести к очередному сбою. В результате конечному пользователю приходится
дольше ожидать ответа с ошибкой, пока код многократно совершает вызовы.
Функция повторной попытки потребляет программные потоки и может при-
вести к каскадному сбою.
Реализация паттерна Bulkhead («Переборка») 179
Паттерн «Предохранитель» (также называют «Прерыватель» или «Переклю-
чатель») (Circuit Breaker) проверяет работоспособность нижележащих зави-
симостей. Он обнаруживает проблемы в этих зависимостях и реализует логику
щадящего отклонения запросов, пока не определит, что зависимость снова ра-
ботает. Этот паттерн может быть реализован на уровне хранения данных для от-
слеживания работоспособных и неработоспособных запросов за период времени.
Если определенный процент запросов оказался неработоспособен за этот период
или общее количество исключений превысило пороговое значение (независимо
от процента), «Переключатель» помечается как включенный. В такой ситуации
все запросы выдают исключения, не интегрируясь с зависимостью, в течение
определенного периода тайм-аута. Когда период тайм-аута истечет, небольшая
доля запросов попытается интегрироваться с зависимостью, чтобы проверить,
не восстановилась ли работоспособность. После того как достаточный процент
запросов станет работоспособен за период времени или не будут наблюдаться
ошибки, «Переключатель» снова будет выключен, а запросы продолжат инте-
грироваться в нормальном режиме.
В основе реализации паттерна лежит конечный автомат, который отслеживает зна-
чения или обменивается значениями счетчиков работоспособных/неработоспособ-
ных запросов. Информация о состоянии сервисов может храниться в DynamoDB,
Redis/Memcached или другом хранилище данных с низкой задержкой.
Перейдем к архитектурному паттерну Bulkhead («Переборка»), который помо-
гает сократить зависимости между сервисами и взять под контроль ситуацию
в случае получения ошибки сервисом.
Реализация паттерна Bulkhead («Переборка»)
Переборки — элементы конструкции корабля, используемые для создания от-
дельных водонепроницаемых отсеков. Их основное назначение — ограничить
последствия пробоины в корпусе, чтобы вода не распространялась по всему
судну. Такая конструкция критически важна для обеспечения безопасности,
минимизируя риск затопления всего корабля при получении повреждения.
Аналогичная концепция помогает ограничить последствия сбоев в архитектуре
больших систем, которые желательно секционировать для ослабления зави-
симостей между сервисами. Идея заключается в том, что один сбой не должен
приводить к сбою всей системы, как показано на рис. 4.10.
Рис. 4.10. Паттерн «Переборка»
180 Глава 4. Паттерны проектирования архитектур решений
В паттерне «Переборка» элементы приложения изолируются в пуле сервисов,
который имеет высокую зависимость; в случае сбоя одного элемента другие про-
должают обслуживать последующие сервисы. На рис. 4.10 сервис 3 разбивается
на два пула. Если в сервисе 3 произойдет сбой, то последствия для сервиса 1
или сервиса 2 будут определяться их зависимостью от пула, но это не означает
выхода из строя всей системы. Ниже перечислены важные обстоятельства, ко-
торые необходимо учитывать при внедрении паттерна «Переборка», особенно
в модель общих сервисов.
• Приложение не должно выходить из строя из-за сбоя одного сервиса.
• Определите, приемлемо ли менее эффективное использование ресурсов. Про-
блемы с производительностью в одном сегменте должны быть переносимы
приложением в целом.
• Выберите полезную детализацию. Проследите, чтобы пулы сервисов были
управляемыми и справлялись с нагрузкой приложения.
• Отслеживайте производительность каждого сегмента сервисов и придержи-
вайтесь условий SLA. Убедитесь, что все подвижные части работают вместе,
и протестируйте приложение при выходе из строя одного пула сервисов.
Определите сегмент сервиса для каждого требования — технического или биз-
нес-требования. Паттерн должен предотвращать каскадные сбои в приложениях
и изолировать критических потребителей от стандартных.
Серверы старых приложений часто имеют конфигурацию с жестко закодиро-
ванными IP-адресами или именами DNS. Чтобы модернизировать и обновить
сервер, необходимо изменить все приложение и провести его повторную
проверку. В таких случаях адрес сервера должен оставаться неизменным.
В следующем разделе вы узнаете, как в такой ситуации может помочь паттерн
«Плавающий 1Р».
Создание паттерна Floating IP (Плавающий IP)
Монолитные приложения обычно имеют много зависимостей от сервера, на
котором они развертываются. В конфигурации и коде приложения часто при-
сутствуют жестко закодированные параметры, относящиеся к именам DNS
и IP-адресам. Жестко закодированная конфигурация IP создаст проблемы, если
потребуется поднять новый сервер вместо исходного. Кроме того, все приложе-
ние не должно терять работоспособность при обновлении, что может привести
к значительным простоям.
В таких ситуациях необходимо создать новый сервер с IP-адресом и именем
DNS старого сервера. Это можно сделать путем переноса сетевого интерфейса
с неработоспособного экземпляра на новый сервер. Сетевой интерфейс обычно
базируется на сетевом адаптере (NIC, Network Interface Card), обеспечиваю-
щем коммуникацию между серверами в сети. Этот компонент может быть как
Реализация паттерна Bulkhead («Переборка») 181
аппаратным, так и программным. Перенос сетевого интерфейса означает, что
новый сервер принимает на себя все функции старого. Приложение может рабо-
тать с прежним именем DNS и IP-адресом. Также это позволяет легко отменить
изменение, перенеся сетевой интерфейс на исходный экземпляр.
Публичная облачная платформа (например, AWS) упрощает эту операцию,
предоставляя технологии EIP (Elastic IP) и ENI (Elastic Network Interface). Если
в одном экземпляре произойдет сбой и трафик нужно будет направить другому
экземпляру с таким же публичным IP-адресом, адрес EIP можно перенести
с одного сервера на другой, как показано на рис. 4.11.
Рис. 4.11. Паттерн «Плавающий 1Р»
Поскольку переносится EIP, обновление DNS может не потребоваться. EIP
может перемещать публичный IP-адрес сервера между экземплярами. Если
вам нужно переместить и публичные, и частные IP-адреса, используйте более
гибкий механизм — например, ENI (показанный в правой части диаграммы).
ENI может перемещаться между экземплярами, и можно использовать один
публичный и частный адрес для маршрутизации трафика или обновления
приложения.
Мы рассмотрели несколько архитектурных паттернов с развертыванием прило-
жений на виртуальной машине. Однако при использовании виртуальной машины
вам может понадобиться помощь. Чтобы оптимизировать эксплуатацию, можно
развертывать приложение в контейнерах. Контейнеры лучше всего подходят
для развертывания микросервисов. В следующем разделе рассматривается раз-
вертывание на основе контейнера.
182 Глава 4. Паттерны проектирования архитектур решений
Развертывание приложения в контейнере
В мире постоянно изобретаются новые языки программирования, развиваются
новые технологии. Разные технологические стеки приложений требуют разных
аппаратных и программных сред развертывания. Часто возникает необходимость
в выполнении приложений на разных платформах и миграции между платфор-
мами. Решения требуют формата, который может выполняться где угодно и при
этом является целостным, легковесным и портируемым.
Подобно тому как транспортные контейнеры стандартизируют перевозку гру-
зов, программные контейнеры стандартизируют транспортировку приложений.
Платформа Docker — инструмент, который упаковывает в контейнер всё, что
может понадобиться приложению для запуска: структуру файловой системы,
демоны, библиотеки и зависимости. Контейнеры обеспечивают изоляцию про-
граммного продукта в соответствующей среде разработки и промежуточной
(стейдж) среде. Такая изоляция чрезвычайно важна, поскольку она предотвра-
щает возникновение конфликтов при запуске разных приложений разными
командами в одной базовой инфраструктуре.
Виртуальные машины (VM) изолируются на уровне операционной системы,
а контейнеры — на уровне ядра. Такая изоляция позволяет нескольким при-
ложениям выполняться в однохостовой ОС, но при этом иметь собственные
файловые системы, хранилище данных, оперативную память, библиотеки и, что
самое главное, собственное представление системы.
Виртуальная машина
Рис. 4.12. Виртуальные машины и контейнеры
для развертывания приложений
Развертывание приложения в контейнере 183
Как показано на рис. 4.12, контейнеры позволяют развернуть несколько при-
ложений на одной виртуальной машине. Каждое приложение располагает
собственной средой выполнения, так что можно запускать много отдельных
приложений при одном и том же количестве серверов. Контейнеры совместно
используют ядро операционной системы на машине. Они предоставляют такие
преимущества, как быстрый запуск и эффективное потребление вычислитель-
ных ресурсов (например, оперативной памяти). Образы контейнеров строятся
с учетом уровней файловой системы и могут совместно использовать общие
файлы. Совместно используемые ресурсы сокращают нагрузку на диск и уско-
ряют процесс загрузки образов контейнеров.
Почему популярность контейнеров растет и какими преимуществами они об-
ладают?
Преимущества контейнеров
Когда речь заходит о контейнерах, часто возникают следующие вопросы.
• Зачем нужны контейнеры, если есть экземпляры?
• Разве экземпляры не обеспечивают изоляции от базового оборудования?
Вопросы вполне резонные, но такая система, как Docker, дает целый ряд пре-
имуществ. Одно из них — возможность полноценного использования ресурсов
виртуальной машины за счет размещения нескольких приложений (на разных
портах) в одном экземпляре.
Docker использует некоторые возможности ядра Linux (а именно пространства
имен ядра и группы) для достижения полной изоляции между своими процес-
сами, как показано на рис. 4.13.
Как следует из диаграммы, на одной машине могут выполняться два и более
приложения, требующих разных версий среды выполнения Java, поскольку
каждая конфигурация Docker имеет собственную версию Java и набор уста-
новленных библиотек. В свою очередь, уровень контейнеров в инфраструктуре
приложения упрощает декомпозицию приложения на микросервисы, которые
могут выполняться параллельно на одном экземпляре. Назовем основные
преимущества контейнеров.
• Портируемая среда выполнения приложений: контейнеры предоставляют
платформенно-независимую функциональность. Вы строите приложение
один раз и развертываете его где угодно независимо от используемой опе-
рационной системы.
• Ускорение циклов разработки и развертывания: изменяйте приложение
и запускайте его где угодно с быстрым временем загрузки (обычно в пределах
нескольких секунд).
• Пакетные зависимости и приложение в одном артефакте: упакуйте код вме-
сте с библиотеками и зависимостями, чтобы запускать приложение в любой
операционной системе.
184 Глава 4. Паттерны проектирования архитектур решений
• Запуск разных версий приложения: приложения с разными зависимостями
выполняются одновременно на одном сервере.
• Возможность полной автоматизации: управление контейнерами и разверты-
ванием осуществляется при помощи скриптов, что способствует снижению
затрат и риска ошибок.
• Повышение эффективности использования ресурсов: контейнеры обеспе-
чивают эффективное масштабирование и высокую доступность; на серверах
приложения можно развернуть сразу несколько копий одного контейнера.
• Простота управления безопасностью: контейнеры зависят от платформы,
а не от приложения.
Рис. 4.13. Уровень контейнеров в инфраструктуре приложений
Контейнерное развертывание становится очень популярным благодаря своим
преимуществам.
Существует много способов организации контейнеров. Рассмотрим контейнерное
развертывание более подробно.
Контейнерное развертывание
Сложные приложения с несколькими микросервисами можно быстро развернуть
с помощью механизма контейнерного развертывания. С контейнерами построе-
ние и развертывание приложения становятся более управляемыми, так как среда
остается неизменной. Постройте контейнер в режиме разработки, переведите
Развертывание приложения в контейнере 185
его в среду тестирования, а затем выпустите на продакшен. Контейнерное раз-
вертывание особенно полезно в гибридных облачных средах. С контейнерами
проще поддерживать согласованность сред между микросервисами. Так как
микросервисы не всегда поглощают много ресурсов, их можно разместить в од-
ном экземпляре для сокращения затрат.
Иногда клиенты используют короткие рабочие процессы, требующие создания
временных сред. Такими средами могут быть системы очередей или задания
непрерывной интеграции, которые не всегда эффективно используют ресурсы
сервера. Сервисы оркестрации контейнеров (такие, как Docker или Kubernetes)
могут стать хорошим обходным решением, позволяющим создавать контейнеры
в экземпляре и удалять их оттуда.
Платформа легковесной контейнерной виртуализации Docker предоставляет ин-
струменты управления приложениями. Для запуска контейнеров ее автономную
версию можно установить на любом компьютере. Kubernetes — сервис оркестрации
контейнеров, работающий с Docker и другой контейнерной платформой. Kubernetes
поддерживает автоматизированное управление контейнерами и качественно реа-
лизует аспекты безопасности, сетевых коммуникаций и масштабирования.
Контейнеры помогают компаниям создавать больше объектно-ориентированных
рабочих нагрузок, и провайдеры публичных облачных платформ (такие, как
AWS) расширяют сервисы для управления контейнерами Docker и Kubernetes.
На рис. 4.14 представлено управление контейнерами Docker с использованием
сервиса Amazon ECS (Elastic Container Service). Это полностью управляемый
эластичный сервис для автоматизации масштабирования и координации кон-
тейнеров Docker.
Рис. 4.14. Архитектура контейнерного развертывания
186 Глава 4. Паттерны проектирования архитектур решений
В предыдущем примере несколько контейнеров развертываются на одной вир-
туальной машине, управляемой через Amazon ECS; это упрощает коммуникации
между агентами и управление кластерами. Все запросы пользователей распро-
страняются с использованием балансировщика нагрузки между контейнерами.
Аналогичным образом AWS предоставляет Amazon EKS (Elastic Kubernetes
Service) для управления контейнерами с использованием Kubernetes.
Контейнеры — обширная тема, и вы, как архитектор решений, должны быть
знакомы со всеми доступными вариантами. В этом разделе был приведен лишь
краткий обзор контейнеров. Если вы хотите использовать контейнеры для раз-
вертывания микросервисов, эту тему необходимо изучить глубже. Архитектура
на основе контейнеров рассматривается в следующем разделе.
Построение архитектуры на базе контейнеров
Как вы узнали из предыдущего раздела, контейнеризация помогает создавать
среды для воспроизводимых и масштабируемых приложений. Чтобы начать
работать с контейнерами, необходимо определить пилотную рабочую нагрузку,
для управления которой используется оркестрация контейнеров. Существующие
микросервисные компоненты можно развернуть в контейнерах. После выявления
пробелов в архитектуре и эксплуатационных потребностей можно определить
стратегию миграции для перемещения рабочей нагрузки в контейнеры.
Миграция в контейнеры может быть непростой задачей, если приложения не
были изначально спроектированы для работы в контейнеризованной среде. Дело
в том, что многие приложения обычно хранят файлы локально и полагаются
на сессии с состоянием. При миграции в контейнеры важно уделить внимание
этим специфическим требованиям и убедиться, что приложения нормально
функционируют в контейнерной среде.
При выборе платформ контейнеров существуют разные варианты: Docker,
OpenShift, Kubernetes и т. д. Впрочем, все более популярным оркестратором
контейнеров становится Kubernetes — инструмент с открытым исходным
кодом. Провайдеры публичных облачных платформ (такие, как AWS) так-
же предоставляют платформы для управления контейнерами — такие, как
Amazon ECS для Docker и Amazon EKS для Kubernetes. Эти облачные сер-
висы предлагают так называемую контрольную плоскость (control plane) для
выбора различных вариантов самоуправляемых узлов, управляемых узлов
или бессерверных конфигураций с AWS Fargate. Контрольная плоскость
служит центральным интерфейсом, обеспечивающим возможность орке-
страции и оперативный надзор за контейнеризованными приложениями и их
ресурсами. Например, если вы используете Amazon EKS для развертывания
приложения на базе микросервисов, контрольная плоскость Kubernetes, на-
ходящаяся под управлением AWS, обеспечит координацию развертывания
контейнеров, а также управления состоянием и нужными конфигурациями.
Развертывание приложения в контейнере 187
Такая конфигурация позволяет сосредоточиться на разработке приложений
вместо управления инфраструктурой.
На рис. 4.15 изображено выполнение сервиса с состоянием (stateful) в Amazon
EKS на выбранном языке программирования — таком, как Java или .NET.
С учетом архитектуры можно управлять состоянием сессии в базе данных
Redis.
Рис. 4.15. Развертывание приложения с состоянием в контейнере
Как показано на диаграмме, архитектура на базе контейнеров включает несколько
ключевых компонентов:
• Amazon Virtual Private Cloud (VPC) с определенными подсетями.
публичная подсеть: обеспечивает хостинг балансировщика нагрузки;
частные подсети: используются для развертывания приложения и базы
данных;
балансировщик нагрузки: отвечает за обеспечение доступа к веб-сайту,
размещенному в его контейнерах;
кластер Amazon Elastic Kubernetes Service (EKS): представляет управля-
емую группу узлов в Kubernetes. Эти узлы отвечают за работу нескольких
контейнеров приложений;
база данных Amazon ElastiCache Redis: используется для хранения со-
стояния пользовательской сессии.
Эта архитектура позволяет масштабировать приложение за счет хранения
пользовательских сессий в базе данных Redis. Заметим, что реализация этого
решения может потребовать изменений в коде приложения, что может оказаться
неприемлемым в некоторых сценариях.
188 Глава 4. Паттерны проектирования архитектур решений
Вы познакомились с различными архитектурными паттернами, ориентирован-
ными на разработку приложений. Теперь поговорим о данных. Они являются
неотъемлемой частью проектирования любой архитектуры, и большая часть
архитектуры сосредоточена на сборе, хранении и визуализации данных. В следу-
ющем разделе более подробно рассматривается работа с данными в архитектуре
приложения.
Работа с базой данных в архитектуре приложения
Данные играют центральную роль в разработке любого приложения, и их
масштабирование всегда создает немало проблем. Эффективная работа
с данными снижает задержку и повышает производительность приложения.
В разделе «Построение архитектуры на базе кэша» вы узнали, как повысить
эффективность получения часто запрашиваемых данных за счет размещения
кэша перед базой данных (паттерн «Кэширование на уровне приложения»).
Вы можете разместить перед базой данных кэш Memcached или Redis, что
позволит избежать большого количества обращений к базе данных и снизить
задержку получения данных.
С ростом числа пользователей приложения приходится обрабатывать большие
объемы данных при работе с реляционной БД. Вам придется увеличить объем
хранилища либо провести вертикальное масштабирование сервера базы данных
с установкой дополнительной памяти или повышением мощности процессора.
Если говорить о горизонтальном масштабировании, то оно оказывается более
сложным в контексте реляционных баз данных. В приложениях с интенсивным
чтением горизонтальное масштабирование может обеспечиваться созданием
реплики для чтения. Все запросы на чтение направляются репликам для чтения,
а узел основной базы данных обслуживает запросы на запись и обновление.
Так как реплика для чтения использует асинхронную репликацию, это может
создать задержку. Вариант с репликами для чтения выбирается в случаях, когда
в приложении допустимы миллисекундные задержки.
Шардирование баз данных применяется для создания схемы «ведущий — ве-
дущий» (multi-master) реляционной базы данных и для внедрения концепции
горизонтального масштабирования. Метод шардирования используется для
улучшения производительности записи с несколькими серверами баз данных.
База данных структурируется и сегментируется на идентичные разделы, при
этом соответствующие столбцы таблицы служат ключами для распределения
процесса записи.
Как показано на рис. 4.16, клиентская база данных может быть разделена на
несколько сегментов.
Как показано на диаграмме, без шардов все данные находятся в одном разделе —
например, имена всех пользователей хранятся в одной базе данных. При шар-
дировании данные разбиваются на большие блоки, называемые шардами.
Развертывание приложения в контейнере 189
Например, имена всех пользо-
вателей, начинающиеся на
буквы от А до I, хранятся в од-
ной базе данных, от J до R —
в другой, и от S до Z — в тре-
тьей. Во многих сценариях
шардирование обеспечивает
более высокую производи-
тельность и операционную
эффективность.
Применение Amazon RDS для
шардирования БД на бэкен-
де подразумевает установку
соответствующего ПО (на-
пример, MySQL) с системой
хранения данных Spider на эк-
земпляре Amazon ЕС2. Следо-
вательно, можно начать с со-
здания нескольких баз данных
RDS и использовать их для
шардирования на бэкенде.
ШардЗ
Amazon RDS
MySQL
Рис. 4.16. Сегментация базы данных
Но что, если основной экземпляр БД выйдет из строя? В таком случае для базы
данных необходимо обеспечить высокую доступность. В следующем разделе
паттерн «База данных с высокой доступностью» рассматривается более подробно.
Паттерн High-availability Database
(База данных с высокой доступностью)
Чтобы обеспечить высокую доступность приложения, необходимо посто-
янно поддерживать базу данных в рабочем состоянии. Поскольку горизон-
тальное масштабирование реляционных баз данных реализовать непросто,
сложность решения возрастает. Чтобы обеспечить высокую доступность БД,
необходимо иметь резервную реплику ее основного экземпляра, как показано
на рис. 4.17.
Как видно из рис. 4.17, сервер приложения переключается на резервный экземпляр
в случае выхода из строя основного экземпляра. Реплика для чтения берет на себя
нагрузку основного экземпляра, чтобы предотвратить нежелательную задержку.
Основной и резервный экземпляры находятся в разных зонах доступности, так
что приложение продолжит работать даже при выходе из строя целой зоны до-
ступности. Такая архитектура также помогает добиться нулевого простоя, который
может возникнуть в окне обслуживания базы данных. Когда основной экземпляр
отключается для обслуживания, приложение может переключиться на вторичный
резервный экземпляр и продолжить обработку пользовательских запросов.
190 Глава 4. Паттерны проектирования архитектур решений
Основной экземпляр
Amazon RDS
Реплика для чтения
Резервный экземпляр
Amazon RDS
Зона доступности 1
Зона доступности 2
Рис. 4.17. Паттерн «База данных с высокой доступностью»
Для аварийного восстановления следует определить стратегию резервного ко-
пирования и архивации в зависимости от целевой точки восстановления (RPO,
recovery point objective) для частоты создания резервных копий.
Если значение RPO составляет 30 минут, это означает, что организация допускает
потерю данных только за 30 минут. В таком случае резервные копии должны
создаваться через каждые полчаса. При создании резервной копии необходимо
определить, как долго данные могут храниться для пользовательских запросов.
Данные можно хранить в течение шести месяцев как активную резервную ко-
пию, а затем в архивном хранилище в зависимости от требований комплаенса.
Подумайте, насколько часто вам понадобится обращаться к резервной копии,
и определите тип сетевого подключения, необходимый для выполнения требо-
ваний к резервному копированию и восстановлению в соответствии с целевым
временем восстановления (RTO, recovery time objective). RPO и RTO под-
робнее рассматриваются в главе 8 «Факторы надежности архитектуры».
Например, если RTO в вашей компании составляет 60 минут, это означает, что
ваша сеть должна обладать достаточной пропускной способностью для чтения
и восстановления резервной копии в течение часа. Кроме того, определите,
требуется ли хранить в резервных копиях снапшоты полных систем или томов,
присоединенных к системам.
Возможно, вам также понадобится классифицировать свои данные — напри-
мер, если они содержат конфиденциальную информацию (адреса электронной
почты, почтовые адреса, персональные данные и т. д.). Также стоит определить
соответствующую стратегию шифрования данных. Вы больше узнаете о без-
опасности данных в главе 7 «Факторы безопасности».
В зависимости от роста и сложности приложения рассмотрите возможность ми-
грации с РСУБД на базу данных NoSQL. Технология NoSQL может обеспечить
улучшенное масштабирование, управление, производительность и надежность по
Развертывание приложения в контейнере 191
сравнению с большинством реляционных баз данных. Однако процесс миграции
с РСУБД на NoSQL может отнять много времени и усилий.
Любому приложению приходится обрабатывать большой объем данных: истории
посещений, журналов приложения, оценок и отзывов, социальных сетей и т. д.
Анализ этих наборов данных и извлечение полезной информации способствует
экспоненциальному росту организации. В главе 12 «Инженерия данных для
архитектур решений» вы больше узнаете об этих сценариях использования
и паттернах.
А теперь посмотрим, как построить простую в обслуживании систему с исполь-
зованием паттерна «Чистая архитектура».
Паттерн Clean Architecture (Чистая архитектура)
Паттерн «Чистая архитектура», также известный как «Гексагональная архитек-
тура» (Hexagonal Architecture) и «Порты и адаптеры» (Ports and Adapters), —
архитектурный паттерн, используемый при проектировании бизнес-приложений,
предложенный Робертом С. Мартином (Robert С. Martin). Паттерн выводит
на первый план разделение ответственности, удобство обслуживания и тести-
руемость. Он направлен на создание гибкой, хорошо адаптируемой и простой
в обслуживании системы.
В паттерне «Чистая архитектура» приложение делится на пять ключевых ком-
понентов. Пример с книжным интернет-магазином поможет понять их смысл.
1. Сущности (внутренний уровень): бизнес-объекты, инкапсулирующие базо-
вые бизнес-правила. Они не зависят от конкретных технологий, баз данных
или фреймворков. Сущности представляют «предметы» в системе и их воз-
можности. В книжном интернет-магазине сущность «книга» может иметь
свойства (название, автор, цена и т. д.) и методы для проверки ее наличия
или применения скидок.
2. Сценарии использования содержат правила, специфические для приложения,
и определяют, как сущности взаимодействуют друг с другом для реализации
конкретных сценариев или историй пользователей. Они координируют поток
данных и действия между сущностями и внешними интерфейсами. Сценарии
использования нейтральны по отношению к технологиям, они сосредоточены
только на бизнес-логике. Например, сценарий использования «Оформление
заказа» может включать проверку покупательской корзины, применение
скидок, вычисление стоимости доставки и обработку платежа.
3. Интерфейсы (порты): интерфейсы определяют контракты для взаимодей-
ствий между разными уровнями системы. Они создают границу, отделяющую
внутренние уровни (сущности, сценарии использования) от внешних (адапте-
ров, фреймворков, драйверов). Такое разделение обеспечивает гибкость и про-
стоту обслуживания. Например, может существовать интерфейс обработки
платежей, который определяет методы для перечисления и возврата средств.
192 Глава 4. Паттерны проектирования архитектур решений
4. Адаптеры реализуют интерфейсы и выполняют преобразования меж-
ду внутренними и внешними уровнями. Они позволяют приложениям
взаимодействовать с такими внешними компонентами, как базы данных,
API и сторонние библиотеки. Адаптеры позволяют изолировать базовую
логику от технологических изменений или внешних зависимостей. Адаптер
базы данных может реализовать интерфейс обращения к данным, который
будет обеспечивать взаимодействие с конкретной технологией базы данных.
5. Фреймворки и драйверы (внешний уровень): этот уровень включает все
технические подробности и инструменты, используемые для построения
приложения. К нему относятся веб-серверы, базы данных, U 1-фреймворки,
сторонние библиотеки и т. д. Этот уровень взаимодействует с адаптерами
для соединения базового приложения с внешним миром. Такое соединение
может включать реализацию RESTful-API, использующего конкретный веб-
фреймворк, создание подключения к базе данных SQL или интеграцию со
сторонним платежным шлюзом.
В паттерне «Чистая архитектура» каждый уровень существует независимо от
других, что позволяет вносить изменения на одном уровне, не оказывая влияния
на другие. Менять базы данных, U 1-фреймворк или бизнес-логику можно без
каскадных эффектов в системе. Так как архитектура имеет четко определенные
интерфейсы, вам будет проще создавать моки (mocks) или заглушки (stubs) для
тестирования. Базовая бизнес-логика может тестироваться независимо от баз
данных, UI или других внешних зависимостей.
При использовании паттерна «Чистая архитектура» старайтесь избегать про-
блемы избыточного проектирования (over-engineering). Для небольших или
простых проектов затраты на реализацию этой архитектуры могут не окупаться.
Перед применением тщательно оцените, оправдывают ли преимущества паттерна
возросшую сложность и увеличение времени разработки.
Паттерн «Чистая архитектура» предоставляет надежную и гибкую основу для
разработки программных продуктов, способных адаптироваться к изменениям
технологий и требований. Ориентация на разделение ответственности и четкие
границы между уровнями улучшают масштабируемость и удобство обслужи-
вания и тестирования. Это мощный паттерн, который может хорошо работать
в сложных системах, но должен применяться с пониманием потребностей и кон-
текста конкретного проекта, чтобы избежать излишнего усложнения.
Итак, мы рассмотрели разные архитектурные паттерны и практики. Теперь
рассмотрим важнейшие антипаттерны, о которых необходимо помнить при
проектировании архитектуры приложения.
Как избежать антипаттернов в архитектуре решений
В этой главе вы узнали о новых способах проектирования архитектуры ре-
шений с разными паттернами проектирования. Часто команды могут откло-
няться от лучших практик из-за нехватки времени или ресурсов. Старайтесь
Развертывание приложения в контейнере 193
по возможности избегать перечисленных ниже антипаттернов проектирова-
ния архитектур. Антипаттерны служат признаком плохо спроектированных
систем.
• Масштабирование осуществляется реактивно и вручную. Когда серверы при-
ложений достигают максимальной емкости и у них не остается доступных
ресурсов, у пользователей прерывается доступ к приложениям. Администра-
тор узнает о проблемах, только когда пользователи начинают сообщать о них.
После этого администратор инициирует процесс запуска нового экземпляра
сервера для снижения нагрузки на существующие. Но у такого решения есть
недостаток — между запуском экземпляра и его фактической доступностью
обычно существует задержка в несколько минут. В этот промежуточный
период пользователи могут сталкиваться с прерываниями в обслуживании
и не могут обращаться к приложению. Следует действовать проактивно
и использовать автомасштабирование для добавления вычислительных
мощностей при достижении сервером определенного порога — например,
60 % загрузки процессора или 60 % использования памяти.
• Отсутствует автоматизация. В случае сбоев серверов приложений админи-
стратор вручную запускает и настраивает новый сервер и вручную оповещает
пользователей. Автоматизация обнаружения нерабочих ресурсов и запуск
ресурсов-заменителей может упростить эксплуатацию. Кроме того, можно
добавить автоматические уведомления при таких изменениях ресурсов.
• Сервер в течение долгого времени поддерживается с жестко закодирован-
ными IP-адресами, что препятствует гибкости. Со временем это ведет к рас-
согласованию конфигураций серверов и, как следствие, неэффективному
распределению ресурсов и к ситуации, когда некоторые ресурсы работают,
когда они не нужны. Желательно, чтобы все серверы были идентичны и имели
возможность переключиться на новый IP-адрес. Все неиспользуемые ресурсы
должны автоматически завершать работу.
• Приложение строится монолитно, а все уровни архитектуры, включая веб-
уровень, уровень приложения и уровни данных, тесно связаны и зависят от
сервера. Если на одном из серверов происходит сбой, ломается все приложе-
ние. Поддерживайте уровень приложения и веб-уровень независимыми; для
этого между ними необходимо добавить балансировщик нагрузки. В случае,
если один из серверов приложения окажется недоступным, балансировщик
нагрузки автоматически перенаправит весь трафик на оставшиеся работо-
способные серверы.
• Приложение жестко связано с сервером, а серверы напрямую обмениваются
данными друг с другом. Аутентификация пользователей и сессии хранятся
на сервере локально, а все статические файлы предоставляются с локального
сервера. Создайте сервис-ориентированную RESTful-архитектуру, в которой
сервисы взаимодействуют друг с другом по стандартному протоколу (такому,
как HTTP). Аутентификация пользователей и сессии должны храниться
в распределенном хранилище с низкой задержкой для горизонтального
194
Глава 4. Паттерны проектирования архитектур решений
масштабирования приложения. Статические ресурсы должны храниться
в централизованном хранилище объектов, отделенном от сервера.
• Одна реляционная база данных используется для всех потребностей, что
создает проблемы с производительностью и задержку. Создайте подходящее
хранилище для разных задач:
NoSQL для хранения пользовательских сессий;
кэш-хранилище данных для доступности данных с низкой задержкой;
хранилище данных для потребностей отчетности;
реляционную базу данных для транзакционных данных.
• В системе присутствует единая точка отказа, а один экземпляр базы данных
обслуживает все приложение. По возможности постарайтесь исключить из
архитектуры единые точки отказа. Установите вторичный сервер (резервный)
и выполните репликацию данных. В случае сбоя основного сервера базы
данных вторичный сервер может принять его рабочую нагрузку.
• Статический контент (например, графика в высоком разрешении и видео)
предоставляется непосредственно с сервера без кэширования. Рассмотрите
возможность использования CDN для кэширования тяжеловесного контента
рядом с местоположением пользователя; это поможет сократить задержку
и время загрузки страницы.
• В системе присутствуют дефекты безопасности, открывающие доступ
к серверу без детализированной политики безопасности. Всегда приме-
няйте принцип наименьших привилегий; это означает, что изначально
доступ запрещен и предоставляется только явно указанной группе поль-
зователей.
В списке перечислены некоторые наиболее распространенные антипаттерны.
В этой книге вы изучите лучшие практики, позволяющие избежать антипат-
тернов при проектировании решений.
Итоги
В этой главе рассматривалось построение надежных и масштабируемых про-
граммных архитектур с помощью различных архитектурных парадигм. Глава
началась с исследования n-уровневой архитектуры и анализа ее основных
компонентов: веб-уровня, уровня приложения и уровня базы данных. Далее
мы обсудили мультитенантную архитектуру SaaS (Software as a Service) и изу-
чили сложности и преимущества объединения разных пользовательских баз
в единой структуре.
Применительно к веб-сервисам в главе был рассмотрен архитектурный стиль
RESTful и приведено подробное описание его принципов и сценариев примене-
ния. Затем мы перешли к построению RESTful-архитектуры интернет-магазина,
получив возможность изучить практический пример реализации.
Итоги
195
После этого мы рассмотрели архитектуры с применением кэширования. Мы
подробно изучили распределение кэшей, паттерны с прокси-серверами (кэши-
рующий прокси-сервер, заменяющий прокси-сервер) и эффективные стратегии
кэширования (например, кэширование приложений). Сравнительный анализ
Memcached и Redis помогает сделать выбор оптимального решения для кэши-
рования.
Значимость архитектурных паттернов была подчеркнута в описаниях паттерна
MVC (модель — представление — контроллер) и методологии DDD (предмет-
но-ориентированное проектирование), позволяющих архитекторам создавать
структурированные, адаптируемые и управляемые системы.
Устойчивость архитектуры была подробно рассмотрена в описании паттер-
на «Предохранитель» (Circuit Breaker) и реализации паттерна «Переборка»
(Bulkhead) для повышения стабильности системы. Знакомство с паттерном «Пла-
вающий 1Р» расширяет инструментарий для обеспечения высокой доступности.
Далее в главе была рассмотрена тема контейнеризации, с описанием преиму-
ществ и планов эффективного развертывания контейнеров. При разговоре об
архитектуре приложений были затронуты стратегии работы с базой данных
и описаны паттерны высокой доступности для обеспечения целостности данных
и непрерывной эксплуатации.
В завершение главы мы коснулись принципов чистой архитектуры и стратегий
избежания антипаттернов в архитектуре решений.
В ходе этого исследования вы получили глубокое представление об особенностях
построения адаптируемых, масштабируемых и перспективных программных
систем. Теперь у вас есть знания, необходимые для того, чтобы лучше ориенти-
роваться в непрерывно изменяющейся среде современных технологий.
ГЛАВА 5
ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
ОБЛАЧНО-ОРИЕНТИРОВАННЫХ
АРХИТЕКТУР
В эпоху стремительной цифровой трансформации бизнес все чаще переходит
на облачные платформы для построения масштабируемых, устойчивых и эко-
номически эффективных решений. Переход на облачно-ориентированные
архитектуры становится стратегической необходимостью для организаций,
стремящихся к динамичности, инновациям и эффективной эксплуатации.
В этой главе будет рассмотрен процесс проектирования и реализации облач-
но-ориентированных архитектур, с особым вниманием к паттернам, дизайну
и лучшим практикам.
Мы подробно поговорим о разных облачно-ориентированных паттернах, включая
принципы проектирования и реальные примеры. Обсудим также антипаттерны
облачно-ориентированных архитектур и практики, которые следует избегать.
В этой главе рассматриваются следующие темы.
• Что такое облачно-ориентированная архитектура?
• Бессерверная архитектура.
• Архитектурные решения с сохранением и без сохранения состояния.
• Микросервисная архитектура.
• Реактивная архитектура.
• Архитектура на базе очереди.
• Архитектура «Каналы и фильтры»
• Архитектура, управляемая событиями.
• Паттерн BFF (Backend for Frontend).
• Антипаттерны облачно-ориентированных архитектур.
К концу главы вы получите прочное понимание паттернов облачно-ориентиро-
ванных архитектур и будете готовы к проектированию, построению и оптими-
зации облачно-ориентированных решений.
Что такое облачно-ориентированная архитектура 197
Что такое облачно-ориентированная
архитектура
В главе 3 «Миграция на облачные платформы и проектирование облачных ар-
хитектур» были представлены разные стратегии облачной миграции, включая
lift-and-shift, смену платформы, повторную покупку, удаление и т. д. Чтобы
пользоваться всеми преимуществами и моделями ценообразования облака, очень
важно принять облачно-ориентированную архитектуру. Облачно-ориентиро-
ванной архитектурой называется методология проектирования для построения
и запуска приложений, которые в полной мере используют преимущества и воз-
можности облачных вычислений. Она подразумевает построение приложений,
обеспечивающих эффективность, масштабируемость и устойчивость в динами-
ческих облачных средах.
Облачно-ориентированные приложения разрабатываются на базе принципов,
по максимуму использующих облачные сервисы, автоматизацию и современные
практики разработки. Назовем ключевые характеристики облачно-ориентиро-
ванных архитектур.
• Микросервисы: облачно-ориентированные архитектуры часто строятся из
небольших слабосвязанных сервисов, которые называются микросервисами.
Каждый микросервис обеспечивает определенную бизнес-функциональность
и может разрабатываться, развертываться и масштабироваться независимо.
• Бессерверные вычисления: облачно-ориентированные приложения часто
используют бессерверные вычисления для достижения бесшовной масшта-
бируемости и сокращения затрат. Этот подход позволяет разработчикам
сосредоточиться на коде и логике приложения, не беспокоясь об управле-
нии серверами. Это делает возможным автоматическое масштабирование
и эффективное использование ресурсов, что может значительно снизить
эксплуатационные затраты. В бессерверной архитектуре приложения упа-
ковываются вместе с их зависимостями, что обеспечивает согласованность
разных сред. Это упрощает бесшовное развертывание, масштабирование
и портируемость приложений.
• Эластичность и масштабируемость: облачно-ориентированные приложения
могут масштабироваться в зависимости от текущей потребности, обеспечивая
эффективное использование ресурсов и экономию средств. Это достигается
посредством автоматического масштабирования и распределения нагрузки.
• Устойчивость и отказоустойчивость: облачно-ориентированные приложе-
ния проектируются с расчетом на отказоустойчивость. Они включают такие
практики, как избыточность, автоматизация восстановления и механизмы
отказоустойчивости для обеспечения непрерывности работы даже при воз-
никновении сбоев.
• Автоматизация: в облачно-ориентированных архитектурах применяется авто-
матизация различных процессов, включая развертывание, масштабирование,
198 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
мониторинг и восстановление. Автоматизация сокращает объем ручного вме-
шательства, повышает эффективность и снижает риск человеческих ошибок.
• Практики DevOps: облачно-ориентированное развертывание способствует
тесному сотрудничеству между командами разработки и эксплуатации. Та-
ким образом формируется культура непрерывной интеграции, непрерывной
поставки и быстрых итераций.
• Отсутствие состояния: облачно-ориентированные приложения про-
ектируются как приложения без сохранения состояния. Это означает,
что их компоненты не зависят от локального состояния сервера. Такой
подход улучшает масштабируемость и упрощает горизонтальное масшта-
бирование.
• API на первом плане: API (программные интерфейсы) играют чрезвычайно
важную роль в облачно-ориентированных архитектурах. Приложения про-
ектируются с четкими и хорошо документированными API, что делает воз-
можными коммуникации между микросервисами и способствует интеграции
с другими сервисами.
• Непрерывный мониторинг и улучшение: в ходе работы облачно-ориенти-
рованных приложений осуществляется непрерывный мониторинг, обеспе-
чивающий оптимальную производительность и надежность. Информация,
основанная на данных, используется для выявления потенциальных областей
с целью улучшения и оптимизации.
При миграции приложений в облако не ставится задача переместить их в текущем
виде. Переход в облако позволяет оптимизировать приложение, в полной мере
воспользовавшись преимуществами облачных платформ, в первую очередь —
моделью оплаты по факту потребления. Это означает, что вы платите только за
те ресурсы, которые фактически использовались. Таким образом обеспечиваются
эластичность и экономическая эффективность, так как появляется возможность
масштабирования в зависимости от потребностей без вложений в фиксирован-
ную инфраструктуру.
Очень важно тщательно планировать ресурсы, чтобы избежать их чрезмерного
выделения и лишних затрат. Приложение можно развернуть ближе к пользова-
телям в разных регионах, чтобы сократить задержку и улучшить взаимодействие
с пользователями. Глобальная доступность облака позволяет охватить более
широкую аудиторию без вложений в открытие физических дата-центров по
всему миру.
Переход с капитальных расходов (СарЕх) на эксплуатационные (ОрЕх) — важ-
ное финансовое преимущество облачных решений. Вместо серьезных вложений
в оборудование и обслуживание на начальном этапе затраты распределяются
во времени. Такой подход облегчает планирование бюджета и позволяет более
эффективно распределять ресурсы. С другой стороны, с распределенными
командами и приложениями управление затратами усложняется. Необходимо
принимать эффективные меры управления затратами в разных командах.
Что такое облачно-ориентированная архитектура 199
Облачно-ориентированная архитектура позволяет организациям пользоваться
всеми преимуществами облачных вычислений, включая масштабируемость,
гибкость и экономическую эффективность. В качестве примера возьмем стри-
минговый мультимедиасервис, чтобы вы увидели отличительные особенности
и преимущества облачно-ориентированных архитектур с бессерверной схемой
по сравнению с локальными архитектурами.
В объектно-ориентированных архитектурах стриминговое приложение проек-
тируется с использованием микросервисов и бессерверных вычислений. Разные
функции приложения (аутентификация, рекомендации контента, кодирование
видео, хранение данных и т. д.) разрабатываются как отдельные микросервисы.
Эти микросервисы инкапсулируются в бессерверных функциях, чтобы вы-
полняться в ответ на определенное событие, или триггер. Например, функции
кодирования видео могут автоматически вызываться при отправке нового ви-
део, а функции рекомендации контента могут реагировать на пользовательские
взаимодействия. Управляемые облачные сервисы работают с базами данных,
обеспечивают хранение, аутентификацию и даже выполнение бессерверных
функций.
В локальной архитектуре приложение размещается на серверах и инфраструк-
туре компании. Монолитное приложение решает все задачи, включая аутен-
тификацию, поставку контента и обработку видео. Масштабирование требует
ручного вмешательства и приобретения дополнительного оборудования.
Переходя на облачно-ориентированную разработку, важно помнить о потенци-
альном риске привязки к провайдеру. Это означает, что архитектура, спроектиро-
ванная с платформенными инструментами и сервисами конкретного облачного
провайдера (например, AWS), может быть с трудом перенесена на платформу
другого провайдера из-за уникальной, проприетарной природы возможностей
каждой платформы. Сервисы на разных платформах могут иметь разные име-
на, а методы для вызова этих сервисов могут значительно различаться. Хотя
облачно-ориентированная функциональность предоставляет мощные возмож-
ности для оптимизации операций на конкретной платформе, она также может
создавать проблемы, если позднее вы решите сменить облачного провайдера.
Тщательно следите за балансом между использованием расширенных возмож-
ностей и поддержанием независимости от платформы.
Переход на облачно-ориентированную архитектуру с бессерверной схемой
имеет ряд преимуществ перед традиционными локальными конфигурациями.
Благодаря сочетанию микросервисов и бессерверных вычислений приложения
демонстрируют высокую производительность и масштабируемость, обеспечи-
вают экономическую эффективность и быстроту инноваций, при этом сохра-
няя устойчивость и отклик в реальном времени на динамические потребности
пользователей.
Рассмотрим бессерверную архитектуру более подробно.
200 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Бессерверная архитектура
Когда вы разрабатываете приложение по традиционному сценарию, необходим
сервер, на котором установлена нужная операционная система и нужные про-
граммы. При написании кода следует убедиться, что сервер работает. В про-
цессе развертывания надо добавить больше серверов, чтобы не отставать от
потребностей пользователей, а также обеспечить механизмы масштабирования
(например, автомасштабирование), чтобы управлять требуемым количеством
серверов для обслуживания запросов пользователей. В такой ситуации значи-
тельные усилия тратятся на управление инфраструктурой и ее обслуживание,
а это не имеет никакого отношения к бизнес-задаче.
Термин «бессерверный» означает, что для размещения кода не нужен сервер,
и это освобождает вас от забот по автомасштабированию, а также ослабляет связи
и снижает затраты. Переход на бессерверную схему позволяет сосредоточиться
на приложении и писать код для реализации функциональности, не беспокоясь
об обслуживании инфраструктуры.
® Когда речь заходит о бессерверной схеме применительно к AWS, первое,
что приходит в голову, - функции AWS Lambda; это сервис FaaS (Function as а
Service), предоставляемый облачной платформой AWS. Чтобы приложение
было сервис-ориентированным, Amazon API Gateway дает возможность
размещения конечных точек RESTful перед функциями AWS Lambda, что
помогает предоставлять доступ к ним как к микросервисам. Amazon DynamoDB
предоставляет высокомасштабируемую базу данных NoSQL, полностью
бессерверное хранилище данных NoSQL, a Amazon Simple Storage Service
(S3) - бессерверное хранилище данных для объектов.
Рассмотрим пример бессерверной архитектуры для реализации защищенного
опроса пользователей в AWS.
На диаграмме изображен рабочий поток в защищенной бессерверной архитек-
туре, используемой для опросного приложения, размещенного в AWS.
1. Клиент отправляет защищенный запрос HTTPS к веб-сайту опроса. Ста-
тическая веб-страница, включая все скрипты стороны клиента для вызовов
AJAX, предоставляется непосредственно из ячейки Amazon S3, настроенной
для веб-хостинга.
2. После прохождения опроса клиент отправляет свои ответы. При этом ини-
циируется вызов AJAX из браузера клиента к шлюзу Amazon API Gateway.
Шлюз предоставляет доступ к необходимым конечным точкам для полу-
чения данных опроса и обеспечивает защиту, чтобы обрабатывались только
авторизованные вызовы.
3. Шлюз Amazon API Gateway имеет встроенную интеграцию с сервисом AWS
CloudTrail, который регистрирует все запросы к API. Это означает, что каждая
Бессерверная архитектура 201
отправка результатов опроса будет зарегистрирована, и вы получите данные
для аудита, которые могут быть полезны для диагностики потерянных данных
или анализа подозрительной активности.
а Облако AWS
Запрос к веб-
сайту опросов
Страница HTML
совершает
вызов AJAX ।
Результаты опроса,
зашифрованные на стороне
сервера
Репозиторий
результатов Amazon S3
Триггер
события
Клиент
Amazon S3
предоставляет
защищенную
страницу опроса
в формате HTML
Amazon API
Gateway
_______ Метаданные
нешифрованного
Функция Lambda
обрабатывает
данные запроса
Вызовы API регистрируются
в AWS CloudTrai I
опроса(без
персональных
данных)
Репозиторий
метаданных опросов
Amazon DynamoDB
Рис. 5.1. Пример бессерверной архитектуры AWS для защищенных опросов
4. API Gateway преобразует входящий вызов AJAX в событие, которое ини-
циирует выполнение функции AWS Lambda. Эта бессерверная функция
отвечает за обработку данных опросов, которая может включать проверку
данных, преобразование и применение бизнес-логики, специфической для
требований опроса.
5. После обработки данных функция Lambda осуществляет безопасную отправку
результатов запросов другой ячейке Amazon S3, выделенной для хранения
этих отправленных данных. Результаты шифруются на стороне сервера; это
гарантирует, что данные при хранении будут защищены от несанкциониро-
ванного доступа.
6. Наряду с зашифрованными результатами опросов в таблице Amazon
DynamoDB параллельно хранятся все нечувствительные метаданные (кроме
персональной информации). Эти метаданные могут включать метки времени,
информацию о версии опроса или другие контекстные данные, актуальные
для будущих запросов, отчетов или аналитических целей.
В связи с растущей популярностью бессерверных архитектур в этой книге вам
еще встретятся примеры архитектур, использующих бессерверные сервисы.
В настоящее время AWS SAM (Serverless Application Model) предоставляет
простой синтаксис для создания функций, API и баз данных, адаптированных
для бессерверных сред. В следующем разделе вы узнаете, какие факторы необ-
ходимо учитывать при проектировании бессерверных архитектур.
202 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Факторы проектирования бессерверных архитектур
При построении бессерверной архитектуры очень важно учитывать ключевые
факторы, обеспечивающие успешное развертывание и функционирование при-
ложения. Бессерверная архитектура особенно хорошо подходит для решений,
которые можно разделить на модульные компоненты. Потенциал такого под-
хода раскрывается, когда приложение удается разбить на обособленные сервисы
с независимым масштабированием. Но если проект подразумевает построение
большой сложной логики в одном монолитном модуле, традиционное решение
на базе серверов может оказаться более предпочтительным.
Несмотря на то что бессерверные архитектуры обладают многочисленными
преимуществами, они часто сталкиваются с проблемой «холодного старта»,
который может повлиять на начальную задержку приложения. Хотя пользо-
вателю инфраструктура может казаться бессерверной, облачные провайдеры
(например, AWS) создают скрытую абстрактную прослойку, которая динами-
чески запускает серверы по мере необходимости. Иногда этот процесс требует
времени, что приводит к задержке («холодному старту») при вызове функции
после длительного бездействия. Важно учитывать проблемы «холодного старта»
при проектировании бессерверной архитектуры и реализовать стратегии для их
преодоления, чтобы приложение быстро реагировало и работало эффективно.
Рассмотрим практический пример: разработку системы уведомлений в реальном
времени для платформы социальной сети. Система должна отправлять мгно-
венные уведомления на устройства пользователя каждый раз, когда он получает
лайки, комментарии или запрос на добавление в друзья. Ниже перечислены
некоторые критические факторы бессерверной архитектуры для системы уве-
домлений.
• Детализированная структура функции: разбейте логику приложения на
небольшие обособленные функции. Каждая функция должна решать кон-
кретную задачу или обрабатывать конкретное событие. Такая детализация
обеспечивает эффективное использование ресурсов и улучшает масшта-
бируемость. У вас могут быть отдельные функции для отправки лайков,
комментариев и запросов на добавление в друзья.
• Отсутствие состояния: бессерверные функции проектируются так, чтобы
не сохранять состояния. Все управление необходимым состоянием должно
осуществляться извне (например, в базе данных или в сервисе хранения
данных). Тем самым гарантируется, что функции смогут масштабироваться
и их можно будет легко заменять без последствий для поведения прило-
жения. Убедитесь, что каждая функция не хранит состояния и не зависит
от локальной памяти. Все необходимые данные (например, предпочтения
пользователей или история уведомлений) должны храниться в базе данных.
• Событийное проектирование: бессерверная архитектура хорошо подхо-
дит для приложений, управляемых событиями. Проектируйте функции
так, чтобы они срабатывали в ответ на определенные события: действия
Бессерверная архитектура 203
пользователей и изменения данных. Например, когда пользователь получает
новый запрос на добавление в друзья, событие может вызвать соответству-
ющую функцию.
• «Холодный старт»: бессерверные функции могут сталкиваться с задержкой
при первом вызове (так называемый холодный старт). Это может задержать
доставку уведомлений, поэтому архитектура должна быть спроектирована
так, чтобы минимизировать влияние «холодных стартов» — например, с ис-
пользованием выделенного параллелизма для поддержания определенного
количества экземпляров функции в «теплом» состоянии, готовом к обработке
входящих запросов.
• Масштабируемость: бессерверные платформы автоматически масштабируют
функции в зависимости от спроса. Это позволяет приложению обрабаты-
вать неожиданные выбросы трафика без ручного вмешательства. С ростом
пользовательской активности система будет обрабатывать таким способом
большее количество уведомлений.
• Факторы производительности: следует понимать ограничения бессервер-
ных платформ — например, времени выполнения и памяти. Оптимизируйте
функции для производительности, чтобы система уведомлений быстро реа-
гировала даже в периоды повышенного трафика.
• Распределенная трассировка и мониторинг: реализуйте мониторинг и рас-
пределенную трассировку, чтобы получать информацию о производитель-
ности бессерверных функций. Она будет критична для выявления «узких
мест» и диагностики проблем при доставке уведомлений.
• Безопасность: реализуйте лучшие практики безопасности для бессерверных
архитектур, чтобы предотвратить несанкционированный доступ к уведомле-
ниям. К этой категории относятся аутентификация, авторизация и шифро-
вание данных при хранении и передаче.
• Управление затратами: хотя бессерверные решения могут быть экономически
эффективными, очень важно организовать мониторинг использования и за-
трат. Настройте сигналы о превышении бюджета и воспользуйтесь средствами
поставщика для анализа расходов. С бессерверными решениями вы платите
за время выполнения, поэтому оптимизируйте код для его сокращения и рас-
смотрите возможность применения средств анализа затрат для мониторинга
использования.
• Хранение данных: выберите подходящие варианты хранения данных (напри-
мер, управляемая база данных, хранилище объектов или хранилище данных).
Обеспечьте сохранение данных при вызовах функций. В системе из нашего
примера пользовательские предпочтения и история уведомлений будут
храниться в управляемой базе данных, обеспечивая согласование данных
между вызовами функций.
• Зависимости: помните о зависимостях функций. Включение лишних биб-
лиотек или компонентов может увеличить размер развертываемого пакета
204 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
и повлиять на производительность. Минимизируйте зависимости, чтобы
пакет развертывания функции был компактным и эффективным.
• Тестирование и отладка: разработайте эффективные стратегии тестирования
для бессерверных функций. Используйте локальные эмуляторы и средства
отладки, предоставленные облачным провайдером.
• Использование управляемых сервисов: термин «бессерверный» не означает,
что каждый компонент должен быть функцией. Используйте управляемые
сервисы для других частей архитектуры приложения: баз данных, очередей
и аутентификации.
• Комплаенс и регулирование: учитывайте все требования соответствия стан-
дартам или нормам, которые применяются к вашему приложению, особенно
при работе с чувствительными данными или в отраслях со строгим зако-
нодательством. Убедитесь, что архитектура соответствует нормам защиты
данных, особенно при обработке персональной информации.
Тщательно учитывая эти факторы, можно создать четко спроектированные бес-
серверные приложения, которые получают преимущества автомасштабирования,
экономии и упрощенного управления. Бессерверная архитектура обеспечивает
масштабируемость, экономическую эффективность и быструю доставку уведом-
лений без отвлечения ресурсов на управление инфраструктурой.
При разработке бессерверной архитектуры отсутствие состояния играет клю-
чевую роль. Проектируя приложения без сохранения состояния, вы сокращаете
зависимость от состояний сессий под управлением сервера, что, в свою очередь,
улучшает масштабируемость. Архитектура без сохранения состояния чрезвы-
чайно важна для масштабирования облачно-ориентированных архитектур.
Рассмотрим эту тему более подробно.
Дизайн архитектуры с сохранением
и без сохранения состояния
Архитектурные паттерны с сохранением и без сохранения состояния представ-
ляют два разных подхода к управлению взаимодействиями «клиент — сервер»
в приложениях. Архитектуры без сохранения состояния (stateless) рассматри-
вают каждый запрос от клиента как отдельную независимую транзакцию, не
требующую знания предыдущих транзакций. Такой подход упрощает проекти-
рование и улучшает масштабируемость, так как любой сервер может реагировать
на любой запрос без необходимости поддерживать информацию сессии. В свою
очередь, архитектуры с сохранением состояния (stateful) хранят сессионную
информацию клиента между запросами. Взаимодействия становятся более
персонализированными и контекстными, но это происходит за счет повышения
сложности при управлении данными сессий и проблемами с масштабированием,
так как состояние должно быть согласованным и синхронизированным между
экземплярами серверов.
Дизайн архитектуры с сохранением и без сохранения состояния 205
При проектировании сложных приложений (например, сайтов интернет-магази-
нов) необходимо обрабатывать состояние приложения для поддержания потока
активности, в котором пользователи могут выполнять цепочки операций (до-
бавление товара в корзину, оформление заказа, выбор метода доставки, оплата).
Пользователи могут использовать разные каналы для обращения к приложению
и с высокой вероятностью будут переключаться между устройствами — напри-
мер, добавлять товары в корзину с мобильного устройства, а затем завершать
оформление и проводить оплату с ноутбука. В такой ситуации необходимо
сохранять пользовательскую активность между устройствами и поддерживать
состояние пользователя до завершения транзакции. Таким образом, для вы-
полнения этого требования в архитектуре и реализации приложения должно
быть запланировано управление пользовательскими сессиями.
Чтобы убрать состояние из приложений, информацию пользовательских сес-
сий необходимо сохранять на уровне базы данных (например, в базе данных
NoSQL). Состояние представления может совместно использоваться разными
веб-серверами или микросервисами.
Традиционно монолитное приложение использует архитектуру с сохранением
состояния, при этом информация пользовательской сессии хранится на сервере,
а не во внешней базе данных.
Ключевое отличие архитектур без сохранения и с сохранением состояния проявля-
ется в подходе к хранению данных сессий. В приложениях с сохранением состояния
сессионная информация хранится локально на сервере, что означает, что она не
может легко использоваться совместно с другими серверами. Эта конфигурация
создает проблемы с масштабируемостью и плохо подходит для современных микро-
сервисных архитектур, так как требует, чтобы все последующие запросы от того
же пользователя маршрутизировались к исходному серверу, который обработал
первый запрос. Это может значительно ограничить способность приложения
масштабироваться по нескольким серверам или экземплярам.
Архитектуры без сохранения состояния не хранят сессионные данные на сервере,
позволяя любому серверу обработать любой запрос, который улучшает масшта-
бируемость и гибкость. Выбор между принятием подхода с сохранением или
без сохранения состояния зависит от требований приложения, а именно того,
как оно выдерживает баланс необходимости масштабирования с потребностью
непрерывных персонализированных пользовательских взаимодействий.
Архитектура с сохранением состояния
В приложении с сохранением состояния информацию о состоянии обрабатывает
сервер, так что, когда пользователь создает соединение с конкретным сервером,
ему придется работать с этим сервером, пока транзакция не завершится. Можно
установить балансировщик нагрузки перед приложением с сохранением со-
стояния, но для этого необходимо активировать закрепленные (sticky) сессии
в балансировщике нагрузки.
206 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Закрепленные сессии — метод, используемый для направления всех запросов от
конкретного пользователя на сервер, который обработал исходный запрос. Этот
метод необходим в приложениях с сохранением состояния для обеспечения со-
гласованности сессий, так как он предотвращает потерю сессионных данных при
направлении последующих запросов другим серверам. При использовании закреп-
ленных сессий балансировщик нагрузки отклоняется от стандартной практики
равномерного распределения запросов между серверами, обычно осуществляемого
по циклическому принципу, а вместо этого направляет запросы пользователя кон-
кретному серверу, на котором хранится информация его сессии. Хотя этот метод
поддерживает долгосрочные сессии, он создает определенные проблемы — напри-
мер, опасность перегрузки одного сервера из-за слишком большого количества
одновременных подключений. Чтобы этого избежать, важно реализовать механизм
тайм-аута сессий, чтобы они не поглощали ресурсы сервера до бесконечности.
Часто приложение с сохранением состояния не поддерживает горизонтальное
масштабирование в должной мере, так как состояние приложения хранится на
сервере, который невозможно заменить. Приложение с сохранением состояния
очень хорошо работает при небольшой базе данных. Тем не менее с распростране-
нием интернета логично, что веб-приложение сможет иметь миллионы активных
пользователей. Следовательно, эффективное горизонтальное масштабирование
играет важную роль для обслуживания большой пользовательской базы и обес-
печения низкой задержки приложения.
Архитектура без сохранения состояния
Если вы используете подход без сохранения состояния, ваш дизайн должен
быть в большей степени ориентирован на общее состояние сессии, так как оно
допускает горизонтальное масштабирование.
На рис. 5.2 изображена архитектура приложения без сохранения состояния для
веб-приложения на базе AWS.
Эта архитектура AWS предоставляет защищенную масштабируемую среду
с высокой доступностью для трехуровневого приложения между двумя зонами
доступности. Она использует балансировщик нагрузки Elastic Load Balancer
для распределения трафика между двумя кластерами серверов ЕС2, которые
динамически масштабируются механизмом Auto Scaling в соответствии с из-
меняющимися потребностями. Уровень базы данных, в основе которого лежит
Amazon RDS, включает реплику для чтения для масштабирования запросов
и резервный экземпляр для обработки отказов, обеспечивающий надежность
данных и высокую доступность.
Статический контент предоставляется Amazon S3 и эффективно доставляется
через Amazon CloudFront, при этом AWS Route 53 управляет сервисами DNS
для оптимизации маршрутизации пользовательского трафика. Такая конфигура-
ция обеспечивает операционную устойчивость, экономическую эффективность
Дизайн архитектуры с сохранением и без сохранения состояния
207
и оптимизацию производительности для приложения. Чтобы приложения были
слабосвязанными и масштабируемыми, все пользовательские сессии хранятся
в базе данных NoSQL — например, Amazon DynamoDB.
Рис. 5.2. Архитектура приложения без сохранения состояния
Для идентификатора сессии следует использовать хранилище на стороне кли-
ента — например, данные cookie. Такая архитектура позволяет масштабировать
приложение горизонтально путем добавления новых серверов, не беспокоясь
о потере информации пользовательского состояния. Архитектура без сохранения
состояния избавляет от затрат на создание и обслуживание пользовательских
сессий и обеспечивает согласованность между модулями приложения. Кроме
того, приложение без сохранения состояния выигрывает в производительности,
так как оно сокращает затраты памяти на стороне сервера и исключает проблему
с тайм-аутом сессии.
Реализация архитектуры без сохранения состояния подразумевает такие слож-
ности, как интеграция дополнительных компонентов базы данных для хранения
пользовательских сессий и создание вспомогательного уровня для передачи
актуального состояния пользователя между серверами. Тем не менее при пра-
вильном подходе результат произведет хорошее впечатление на пользователей.
Можно разрабатывать приложения с использованием микросервисного подхода
с паттернами проектирования REST и развертывать их в контейнерах. Для этого
при подключении пользователей к серверам следует применять аутентификацию
и авторизацию.
В следующих разделах вы больше узнаете о микросервисах и паттернах проек-
тирования REST. Так как обращения к информации пользовательской сессии
от нескольких веб-серверов обслуживаются одним хранилищем данных, не-
обходимо действовать осмотрительно, чтобы производительность хранилища
данных не стала «узким местом» системы.
208 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Микросервисная архитектура
В облачно-ориентированных архитектурах микросервисы играют важную роль
в разбиении обширной функциональности на меньшие, более удобные блоки,
которые могут масштабироваться независимо. Такой подход позволяет масшта-
бировать отдельные компоненты по мере необходимости, не влияя на систему
в целом. При использовании микросервисов система проектируется как отказо-
устойчивая. Это означает, что она строится с учетом потенциальных сбоев, что
подразумевает щадящее снижение доступности приложения и предотвращение
широкого распространения отказов уровня всей системы.
Очевидное преимущество микросервисов — необходимость поддерживать мень-
ший объем кода. Микросервисы всегда должны быть независимыми. Каждый
сервис строится без внешних зависимостей, что сокращает взаимные зависимости
между модулями приложения и способствует слабой связанности.
Другая обобщающая концепция микросервисов — ограниченные контексты
(bounded context), то есть блоки, объединяемые для формирования предметной
области бизнеса. Предметной областью бизнеса может быть розничная торговля,
производство автомобилей, продажа книг или социальные взаимодействия, вклю-
чающие полные бизнес-процессы. Отдельный микросервис определяет границы,
по которым инкапсулируются все детали. Для примера рассмотрим платформу
интернет-магазина. В такой системе задействованы несколько микросервисов,
обрабатывающих разные бизнес-операции или бизнес-области. Несколько при-
меров ограниченных контекстов на такой платформе.
• Контекст учетных записей пользователей: микросервис обрабатывает все,
что связано с учетными записями пользователей, включая регистрацию,
управление профилями, вход и аутентификацию. Границы контекста охваты-
вают информацию о пользователях и операции, которые могут выполняться
с этими данными, — например, обновление профиля или сброс пароля. Ни-
какой другой микросервис не управляет этими операциями.
• Контекст каталога товаров: микросервис отвечает за управление перечнем
товаров, категорий и подробными описаниями товаров. Он работает неза-
висимо от контекста учетных записей пользователей, концентрируясь ис-
ключительно на товарах, их организации и отображении для пользователей.
• Контекст обработки заказов: микросервис обеспечивает процесс оформ-
ления заказов, отслеживание заказов и обработку платежей. Он использует
информацию из контекста каталога товаров (идентификаторы товаров, цены
и т. д.) и контекста учетных записей пользователей (например, подробную
информацию о клиенте) для выполнения своих функций, но при этом под-
держивает собственные операции — например, обновление статуса заказа
или обработку возврата товаров.
Каждый ограниченный контекст представляет собой автономную систему с соб-
ственной логикой предметной области и базой данных, которая взаимодействует
Микросервисная архитектура 209
с другими системами через четко определенные API. Эти границы позволяют
разрабатывать, развертывать, масштабировать и обновлять каждый микросервис
независимо от других, делая систему в целом более устойчивой и способной
адаптироваться к изменениям.
Установление подобных границ на платформе интернет-магазина гарантиру-
ет, что изменения в одном контексте (например, добавление новых способов
оплаты в контексте обработки заказов) не повлияют на контексты учетных
записей пользователей или каталогов товаров. Это упрощает обслуживание
и масштабирование системы.
Масштабирование каждого сервиса критически важно при работе с высоко-
нагруженными приложениями, когда разные рабочие нагрузки имеют разные
требования к масштабированию.
Рассмотрим некоторые лучшие практики проектирования микросервисных
архитектур.
• Создание отдельного хранилища данных: команда может выбрать в качестве
хранилища базу данных, которая лучше всего подходит для их микросервиса.
Например, команда, занимающаяся трафиком веб-сайта, может использовать
масштабируемую базу данных NoSQL для хранения полуструктурированных
данных. Команда, занимающаяся обработкой заказов, может выбрать реляци-
онную базу данных для обеспечения целостности данных и согласованности
транзакций. Кроме того, такая схема поможет достичь слабой связанности,
чтобы изменения в одной базе данных не влияли на работу других сервисов.
• Серверы без сохранения состояния: как вы узнали из предыдущего раздела,
«Дизайн архитектуры с сохранением и без сохранения состояния», если
состояние не хранится на сервере, это упрощает масштабирование. Сервер,
вышедший из строя, должно быть легко заменить, а для этого нужно, чтобы
он хранил минимальное состояние (или вообще никакого).
• Создание отдельной сборки: создание отдельной сборки для каждого микро-
сервиса упрощает для команды разработки внесение изменений и делает про-
цесс выпуска новых версий более адаптивным. При таком подходе команда
разработки пишет код только для конкретного микросервиса и не влияет на
другие сервисы.
• Развертывание в контейнере: эта практика позволяет развертывать все
компоненты одним стандартным способом. При использовании контейнеров
можно одинаково развертывать все микросервисы независимо от их природы.
Чтобы управлять контейнером, не заботясь об инфраструктуре, можно вос-
пользоваться сервисами бессерверного развертывания контейнеров — такими,
как Amazon Fargate.
• Бессерверный подход: рекомендуется пользоваться бессерверной платфор-
мой или вспомогательной функцией с возможностями сервиса (например,
AWS Lambda), если микросервисы достаточно просты. Бессерверная архитек-
тура помогает избежать накладных расходов на управление инфраструктурой.
210 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
• Сине-зеленое развертывание: для развертывания приложения лучше всего
создать копию рабочей среды. Разверните там новую функциональность
и маршрутизируйте небольшой процент пользовательского трафика, чтобы
убедиться, что новая функциональность в новой среде работает как было
задумано. После этого увеличивайте трафик, пока новая функциональ-
ность не будет доступна всем пользователям. Вы больше узнаете о сине-
зеленом развертывании в главе 11 «DevOps и фреймворк архитектуры
решений».
• Мониторинг среды: хороший мониторинг позволяет перейти от реакции на
сбои к их активному предотвращению за счет изменения маршрутизации,
масштабирования и управляемого снижения функциональности. Если вы
хотите предотвратить простои приложения, сервисы должны предоставлять
и отправлять информацию о своей работоспособности уровню мониторинга.
В конце концов, кто лучше знает статус сервиса, чем сам сервис? Мониторинг
можно осуществлять многими способами — например, с использованием
плагинов или посредством записи через API мониторинга.
Хотя микросервисные архитектуры обладают рядом преимуществ, модульный
подход требует дополнительных затрат на управление расширенной инфра-
структурой. Тщательно выберите инструменты, которые помогут вам управлять
несколькими модулями и масштабировать их параллельно. При проектировании
микросервисной архитектуры старайтесь использовать бессерверные платформы
там, где это возможно; это позволит справиться с расходами на инфраструктуру
и эксплуатацию.
Рассмотрим пример архитектуры на базе микросервисов для приложения, пред-
назначенного для голосования в реальном времени.
На рис. 5.3 представлена микросервисная архитектура в приложении для го-
лосования. В нем используются небольшие изолированные сервисы, которые
обрабатывают и подсчитывают голоса. Когда кто-то голосует со своего мобиль-
ного устройства, приложение регистрирует каждый голос, а затем сохраняет его
в базе данных NoSQL — Amazon DynamoDB.
Логика приложения содержится в функции AWS Lambda, которая накаплива-
ет все данные голосования пользователей (например, за их любимого актера)
и возвращает итоговые результаты.
В представленной архитектуре происходит следующее.
1. Пользователь отправляет свой голос в текстовом сообщении на телефонный
номер или короткий код, предоставляемый третьей стороной (например,
Twilio).
2. Третья сторона настраивается для отправки содержимого сообщения на
эндпойнт, созданный Amazon API Gateway, а эндпойнт пересылает запрос
функции, встроенной в AWS Lambda.
Микросервисная архитектура 211
3. Функция извлекает голос из содержимого сообщения и записывает результат
вместе с метаданными в таблицу Amazon DynamoDB.
4. Для таблицы включена поддержка DynamoDB Streams, которая отслеживает
изменения в таблицах.
5. После обновления DynamoDB Streams указывает второй функции AWS
Lambda с логикой приложения провести агрегирование голосов (за каждую
секунду) и записать их в другую базу данных DynamoDB. Во второй таблице
хранится только сумма голосов по каждой категории.
6. Дашборд для отображения сводки голосов создается с использованием
HTML и JavaScript и размещается как статический веб-сайт в Amazon
S3. Страница использует AWS JavaScript SDK для запроса к сводной
таблице Amazon DynamoDB и вывода результатов голосования в реальном
времени.
7. Наконец, Amazon Route 53 выступает поставщиком DNS для создания зоны
хостинга, указывающей на специальное доменное имя в ячейке Amazon S3.
Это позволяет размещать статические веб-сайты в ячейках S3 по экономич-
ной бессерверной схеме.
Эта архитектура не только базируется на микросервисах, но и является бессер-
верной. Используя микросервисы, можно создавать приложения из небольших
независимых компонентов. Применение микросервисной архитектуры означает
снижение затрат, размеров и риска изменений, что повышает скорость изменений.
DynamoDB сохраняет голоса
с поддержкой DynamoDB Streams,
которая отслеживает
изменения в таблицах
Отправляется контент
сообщения
Пользователи
отправляют свои
голоса по телефону
в виде сообщения
Функция Lambda
извлекает голос
из сообщения
и сохраняет его
AWS Lambda записывает сумму голосов
в другую таблицу Amazon DynamoDB
Пользователь запрашивает
окончательный результат голосования
Рис. 5.3. Приложение для голосования в реальном времени
на базе микросервисов с AWS
212 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
В распределенных системах с использованием микросервисов важна коорди-
нация между несколькими сервисами. В следующем разделе вы узнаете, как
координировать работу нескольких микросервисов.
Паттерн Saga (Сага)
«Сага» — паттерн проектирования, используемый для управления продолжи-
тельными сложными бизнес-транзакциями. Этот паттерн особенно полезен
в микросервисных архитектурах, когда в одной бизнес-транзакции может быть
задействовано несколько микросервисов. Вместо традиционного двухфазного
коммита паттерн «Сага» делит транзакцию на несколько меньших изолирован-
ных транзакций. Каждая из меньших транзакций обрабатывается отдельными
сервисами, работа которых координируется для обеспечения согласованности
данных между ними. Если в одной из меньших транзакций происходит сбой,
выполняются компенсирующие транзакции для отмены предыдущих шагов.
В сложных системах, в которых несколько сервисов должны работать совместно
для выполнения одной операции (например, обработки заказа или бронирования
билета), паттерн «Сага» гарантирует, что, если в какой-то момент что-то пойдет
не так, вся операция будет либо полностью завершена, либо отменена.
Схема работы паттерна «Сага»:
• декомпозиция: операция, которую необходимо выполнить, разбивается на
меньшие изолированные шаги или транзакции. Каждый шаг соответствует
действию, выполняемому конкретным микросервисом;
• компенсирующие действия: для каждого шага определяется соответствую-
щее компенсирующее действие. Если при выполнении шага происходит сбой
или ошибка, выполняется компенсирующее действие, отменяющее эффекты
предыдущих шагов. Таким образом система возвращается в согласованное
состояние;
• координатор: отвечает за оркестрацию последовательности действий и со-
ответствующих компенсирующих действий. Он инициирует запуск «Саги»,
отслеживает ее прогресс и определяет, были ли завершены все шаги, или
предпринимает необходимые компенсирующие действия;
• локальные транзакции: каждый шаг и его компенсирующие действия инкап-
сулируются в локальной транзакции с соответствующими микросервисами.
Таким образом обеспечивается атомарность операций в каждом микросервисе;
• согласованность в конечном счете: паттерн «Сага» поддерживает согла-
сованность в конечном счете; это означает, что даже при возникновении
сбоя система со временем достигнет согласованного состояния благодаря
либо успешному завершению всей операции, либо откату в согласованное
состояние.
Рассмотрим для примера интернет-магазин, в котором клиент размещает заказ.
Паттерн «Сага» может использоваться для отработки всей процедуры обработки
заказов.
Микросервисная архитектура 213
1. Запуск: сервис заказа начинает новую сагу для обработки заказов.
2. Шаги: сага включает несколько шагов, выполняемых разными микросерви-
сами, — например, проверку доступности товара, оплату заказа, обновление
запасов и оповещение клиента.
3. Компенсирующие действия: определяются соответствующие компенсирую-
щие действия. Например, если товар отсутствует на складе: отмена оплаты,
пополнение запасов и отправка клиенту сообщения с извинениями.
4. Координатор: координатор осуществляет надзор над сагой, проверяя, что
каждый шаг был успешно выполнен или компенсирован. Например, коорди-
нироваться может последовательность шагов от проверки наличия товара до
размещения заказа, взимания платы с клиента и передачи заказа на доставку.
5. Согласованность в конечном счете: если в любой момент произойдет сбой
(например, если попытка списания средств окажется неудачной), иниции-
руются компенсирующие действия, которые должны вернуть систему в со-
гласованное состояние.
Каждый сервис, задействованный в паттерне «Сага», генерирует и прослушивает
события, как показано на рис. 5.4.
Сервис заказов Сервис платежей
Получает запрос на создание заказа
Состояние заказа — «в процессе обработки»
Публикует событие «OrderCreated»
j
Обрабатывает платеж
Сервер запасов
Сервис доставки
Публикует событие «PaymentProcessed»
| Публикует событие «PaymentProcessed»
Проверяет и резервирует товары на складе
Публикует событие «StockReserved»
Публикует событие «StockReserved»
------------------------------►
Планирует доставку
Публикует событие
«ShipmentScheduled»
Публикует событие «ShipmentScheduled»
Обновляет заказ статусом «завершен»
Сервис заказов
Сервис платежей
Сервер запасов
Сервис доставки
Рис. 5.4. Диаграмма последовательности действий паттерна «Сага»
в архитектуре интернет-магазина
214 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Как показано на рис. 5.4, когда сервис завершает свою часть транзакции, он
генерирует событие, которое инициирует следующий сервис в саге.
1. Сервис заказов получает запрос на создание заказа.
2. Сервис заказов запускает сагу, создавая заказ в состоянии обработки и пуб-
ликуя событие OrderCreated (заказ создан).
3. Сервис платежей прослушивает событие OrderCreated, обрабатывает платеж
и публикует событие PaymentProcessed (платеж обработан).
4. Сервис запасов прослушивает событие PaymentProcessed, проверяет, что
товары присутствуют на складе, резервирует их и публикует событие Stock-
Reserved (товар на складе зарезервирован).
5. Сервис доставки прослушивает событие StockReserved, планирует доставку
и публикует событие ShipmentScheduled (отгрузка запланирована).
6. Сервис заказов прослушивает событие ShipmentScheduled и обновляет заказ,
переводя его в статус завершенного.
Если какой-либо из сервисов не может завершить свою часть транзакции, он
публикует компенсирующее событие, чтобы инициировать откат предыдущих
шагов. Например, если сервис запасов обнаруживает, что запас товара недоста-
точен, он может опубликовать событие Stockinsufficient (товара на складе не-
достаточно). Сервис платежей прослушивает это событие и инициирует возврат
платежа. Сервис заказов прослушивает событие Stockinsufficient и обновляет
заказ, переводя его в статус отмененного.
Паттерн «Сага» — вариант дизайна, который решает проблему согласованности
данных в распределенных системах, особенно при работе с микросервисами.
Вместо того чтобы использовать одну крупномасштабную транзакцию для обес-
печения согласованности данных между разными сервисами, паттерн «Сага»
разбивает транзакцию на серию локальных транзакций для каждого сервиса.
Каждая локальная транзакция обновляет базу данных и публикует событие или
сообщение, которое является признаком успеха или неудачи транзакции. С дру-
гой стороны, паттерн «Сага» вводит концепцию согласованности в конечном
счете; это означает, что состояние системы станет согласованным со временем,
но не обязательно немедленно. Кроме того, реализация паттерна «Сага» может
оказаться сложной, так как для него придется обрабатывать сценарии отказов
и следить за тем, чтобы компенсирующие действия правильно отменяли преды-
дущие операции. Часто это требует сложной координации и надежных систем
передачи сообщений для управления асинхронными коммуникациями между
сервисами.
Паттерн «Сага» позволяет разбивать сложные операции на простые шаги, с за-
щитными мерами для обработки отказов и обеспечения целостности данных.
Паттерн улучшает устойчивость в распределенных системах, гарантируя, что
система будет обладать связностью и согласованностью в конечном счете даже
при возникновении сбоев. Тем не менее реализация паттерна «Сага» требует
Микросервисная архитектура 215
тщательного проектирования и координации для эффективной обработки
различных сценариев отказов. Что, если у вас имеется обширная информация,
которая должна быть обработана разными микросервисами, но при этом кон-
солидирована для формирования значимой аналитики? В таких сценариях на
помощь приходит паттерн Fan-out/Fan-in. В следующем разделе он рассматри-
вается более подробно.
Паттерн Fan-out/Fan-in (Разветвление/схождение)
Паттерн проектирования Fan-out/Fan-in («Веерное распределение/сбор» или
«Разветвление/схождение») часто применяется в распределенных системах
для эффективной обработки запросов и агрегирования данных от нескольких
источников. Он полезен в сценариях, требующих сбора, обработки и консоли-
дации данных от разных входящих потоков или источников. Паттерн получил
свое название по тому, как данные разветвляются (Fan-out) на несколько ис-
точников, а затем сходятся (Fan-in) обратно для агрегирования.
Возьмем систему аналитики в реальном времени для платформы социальной
сети. Паттерн Fan-out/Fan-in может быть применен для сбора и обработки
данных по разным пользовательским активностям. Посмотрим, как он работает.
• Фаза разветвления (fan-out):
в фазе разветвления данные собираются из различных источников, вклю-
чая различные микросервисы, API и потоки данных. Каждый источник
отправляет свои данные отдельному обрабатывающему компоненту.
Пользовательские посты, комментарии, лайки, публикации и подписчики
генерируют потоки данных реального времени;
обработчики всех источников работают независимо от других и одно-
временно. Это позволяет организовать эффективную параллельную об-
работку, сокращая время сбора данных от разных источников. С каждым
видом активности связан выделенный обработчик, который вычисляет
различную статистику: коэффициент вовлеченности, популярный контент,
популярные темы и т. д.
• Фаза схождения (fan-in): после завершения раздельной обработки резуль-
таты всех обработчиков агрегируются (в данном примере — для вычисления
общих метрик вовлеченности платформы). Агрегирование может включать
вычисление, суммирование или любые другие операции, необходимые для
получения конечного результата. Из агрегированных данных генерируется
желаемый результат или итоговый отчет. Это может быть простой отчет, свод-
ный анализ или любая другая разновидность консолидированных данных.
В нашем примере данные отображаются для администраторов в виде даш-
борда, на котором в реальном времени выводятся аналитические показатели.
В рассмотренном примере паттерн Fan-out/Fan-in позволяет аналитической
системе эффективно обрабатывать и консолидировать данные по разным
216 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
пользовательским активностям, предоставляя администраторам аналитику
вовлеченности пользователей в реальном времени.
Преимущества паттерна Fan-out/Fan-in
Паттерн Fan-out/Fan-in определяет стратегический подход в распределенных
системах, значительно улучшающий обработку и управление данными. Ключе-
вые преимущества этого паттерна:
• параллелизм: паттерн делает возможной параллельную обработку, ускоряя
сбор и агрегирование данных из нескольких источников;
• эффективность: вместо последовательной обработки данных от каждого
источника паттерн оптимизирует время обработки за счет одновременной
работы с несколькими источниками;
• масштабируемость: каждый источник может обрабатываться независимо
от других, что позволяет эффективно масштабировать систему с ростом
количества источников;
• модульность: паттерн, способствует модульности архитектур за счет отделе-
ния фазы сбора данных (разветвления) от агрегирования (схождение). Такое
разделение упрощает обслуживание и расширение системы.
Хотя паттерн Fan-out/Fan-in дает преимущества в отношении параллельной
обработки и повышения эффективности в распределенных системах, он создает
и специфические проблемы, к которым следует отнестись внимательно. Реа-
лизация этого паттерна повышает сложность из-за необходимости тщательно
координировать многочисленные параллельные задачи, которые он запускает,
и их последующее агрегирование. Обработка ошибок также усложняется, так
как система должна учитывать потенциальные сбои во всех разветвленных
задачах и обеспечить надежные механизмы восстановления для поддержания
согласованности данных.
Этот паттерн также может быть достаточно ресурсозатратным, поскольку тре-
бует значительной вычислительной мощности для управления параллельными
процессами, что может привести к увеличению эксплуатационных затрат и не-
обходимости применения продвинутых стратегий масштабирования. Помимо
этого, стадия агрегирования может стать «узким местом» системы, особенно если
она требует обработки больших объемов данных, а это может создать задержку.
Еще один недостаток — такая система может обеспечить только согласованность
в конечном счете, а это станет проблемой для приложений, требующих обработ-
ки в реальном времени. Наконец, распределенная природа паттерна усложняет
отладку и мониторинг, требуя многоцелевых инструментов для обеспечения
видимости между всеми задачами. Несмотря на эти затруднения, при тщатель-
ном проектировании и управлении паттерн Fan-out/Fan-in остается мощной
стратегией повышения эффективности обработки данных в распределенных
архитектурах.
Микросервисная архитектура 217
В целом паттерн Fan-out/Fan-in полезен при управлении и обработке данных
от разных источников в распределенных системах, реализуя параллельную об-
работку и упрощенное агрегирование.
Увеличение количества микросервисов требует тщательной координации; в ре-
шении этой задачи помогает паттерн Service mesh (Сервисная сеть). Рассмотрим
его более подробно.
Паттерн Service mesh (Сервисная сетка)
В современной разработке ПО микросервисы стали общепринятым принципом
построения гибких и масштабируемых архитектур. Однако с ростом количества
микросервисов управлять их взаимодействиями и обеспечить надежность может
быть сложнее, чем пересечь забитый уличный перекресток.
На помощь приходит концепция сервисной сетки (service mesh), упрощающая
взаимодействия между микросервисами одновременно с повышением их на-
дежности.
Представьте, что вы находитесь на оживленном перекрестке с несколькими
полосами движения. Каждая машина — микросервис, служащий определенной
цели. Чтобы избежать аварий и обеспечить беспроблемное движение, необходи-
мы светофоры, дорожные знаки и правила дорожного движения. Точно так же
сервисная сетка становится «регулировщиком» для микросервисов, управляя
их взаимодействиями и обеспечивая их гармоничную работу.
Сервисная сетка — уровень инфраструктуры, управляющий взаимодействиями
разных сервисов в облачном приложении. Этот уровень обеспечивает надежную
доставку сообщений между этими сервисами. Разработчики могут сосредото-
читься на программировании основного приложения, в то время как сервисная
сетка позаботится о сетевой передаче и безопасности в инфраструктуре системы.
На рис. 5.5 изображена инфраструктура сервисной сетки на примере сервисов
AWS.
Рассмотрим каждый шаг, представленный на рис. 5.5.
1. ЕС2 сервис А представляет экземпляр Amazon ЕС2, на котором работает
сервис (Сервис А). Экземпляры ЕС2 представляют масштабируемые вы-
числительные мощности в облаке AWS (Amazon Web Services).
2. Вызывает сервис В: сервис А инициирует вызов к сервису В. В этой точке
начинается процесс межсервисного взаимодействия.
3. Коммуникации: этот блок представляет уровень коммуникаций, на котором
запрос сервиса А перехватывается для маршрутизации через сетку сервисов.
4. Через Арр Mesh: запрос от сервиса А проходит через AWS Арр Mesh — сер-
висную сетку, предоставляющую сетевые взаимодействия уровня приложе-
ния. Арр Mesh стандартизирует коммуникации между сервисами, обеспечивая
сквозную видимость и высокую доступность для приложений.
218 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
5. Маршрутизируется к сервису В: AWS Арр Mesh маршрутизирует запрос
к соответствующему сервису (в данном примере это сервис В).
6. ECS сервис В: представляет задачу Amazon ECS (Elastic Container Service).
ECS — высокомасштабируемый, высокопроизводительный сервис управле-
ния контейнерами, поддерживающий контейнеры Docker.
7. Вызывает сервис С: после того как сервис В завершит свою обработку, он
вызывает сервис С. Этот вызов может быть частью большей транзакции,
включающей несколько микросервисов.
8. Маршрутизируется к сервису С: AWS Арр Mesh снова маршрутизирует
вызов от сервиса В к сервису С.
9. Lambda сервис С: представляет функцию AWS Lambda для сервиса С. AWS
Lambda позволяет выполнить код без выделения серверов или управления
серверами. Код выполняется только тогда, когда это необходимо, а схема
масштабируется автоматически.
Архитектура абстрагирует сложные взаимодействия сервисов в сервисной сетке,
демонстрируя роль AWS Арр Mesh в управлении, маршрутизации и контроле
коммуникаций между разными сервисами.
Рис. 5.5. Архитектурный паттерн Service mesh (сервисная сетка)
в облаке AWS
Микросервисная архитектура 219
Перечислим основные возможности, предоставляемые сервисной сеткой.
• Управление трафиком: предоставляет детализированный контроль над по-
ведением трафика с подробными правилами маршрутизации, повторными
попытками, обработкой отказов и внедрением сбоев.
• Наблюдаемость: обеспечивает более глубокое понимание приложений
благодаря визуализации, трассировке, мониторингу и регистрации трафика
между сервисами.
• Безопасность: предоставляет автоматизированное взаимное шифрование
трафика TLS (mTLS) между сервисами.
• Соблюдение политик: позволяет определять и устанавливать политики для
всех сервисов независимо от того, где они работают.
• Устойчивость: делает возможной расширенную балансировку нагрузки, тайм-
ауты и повторные попытки, помогая создавать более устойчивые приложения.
Популярный способ реализации сервисной сетки основан на использовании
вспомогательных прокси-серверов. Каждый экземпляр сервиса в микросер-
висном приложении дополняется вспомогательным прокси-сервером, который
обеспечивает все сетевые коммуникации к сервису и от него. Все эти прокси-
серверы соединяются между собой, образуя сетку, отсюда и название service
mesh (англ, mesh — сетка, переплетение).
Сервисные сетки становятся неотъемлемой частью современных облачно-ори-
ентированных архитектур приложений. Они предоставляют разнообразные
реализации, адаптированные для разных потребностей и сред. Самые популярные
реализации сервисных сеток следующие.
• Istio: это комплексное решение предоставляет надежный механизм управ-
ления межсервисными коммуникациями в микросервисной архитектуре.
Оно позволяет разработчикам задавать подробные правила маршрутизации
и политики, реализовывать паттерны устойчивости (такие, как повторные
попытки и переключатели), а также собирать аналитические данные о по-
токах трафика приложения. Возможности Istio по соблюдению политик
и сбору метрик помогают повысить уровень защиты и вести наблюдение за
коммуникациями между сервисами, таким образом повышая надежность
и производительность сети.
• Linkerd: пользуется популярностью благодаря своей простоте и произ-
водительности. Linkerd — сервисная сеть с открытым исходным кодом,
предоставляющая такие важные функции, как обнаружение сервисов,
маршрутизация, обработка отказов и видимость для инфраструктур со-
временных приложений. Система проектировалась с расчетом на легко-
весность, простоту установки и минимальный след в системе, что делает ее
привлекательной для команд, желающих перейти на технологию сервисных
сеток без значительных затрат.
220 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
• AWS Арр Mesh: система, спроектированная специально для пользователей
AWS, представляет собой управляемый сервис, упрощающий управление
и контроль над коммуникациями между микросервисами в среде сервисов
AWS. Арр Mesh поддерживает сетевые взаимодействия уровня приложе-
ния, что позволяет приложениям взаимодействовать по сети с большей
видимостью и контролем. AWS Арр Mesh упрощает конфигурацию сетевых
коммуникаций, предоставляя аналитические данные уровня приложения
и обеспечивая высокую доступность приложений.
• Consul Connect: Consil Connect (часть HashiCorp Consul) обеспечивает
межсервисные коммуникации с автоматическим шифрованием TLS и авто-
ризации, основанной на идентификационных данных. Это платформенно-
независимое решение, предоставляющее согласованный, унифицированный
метод защиты и настройки коммуникаций между сервисами независимо от
используемой платформы. Consul Connect уделяет первоочередное внимание
безопасности и следит за тем, чтобы только авторизованные сервисы могли
взаимодействовать друг с другом, тем самым сокращая риск внутренних угроз.
Хотя сервисные сетки предоставляют целый ряд преимуществ для микросервисных
архитектур (такие, как улучшение межсервисных коммуникаций, повышение уров-
ня безопасности и улучшенная наблюдаемость), необходимо учитывать сложность,
которую они добавляют в инфраструктуру. Внедрение сервисной сетки подразу-
мевает добавление компонентов для управления, мониторинга и обслуживания,
что может повысить эксплуатационные затраты. Этот дополнительный уровень
инфраструктуры требует тщательного планирования, квалифицированных специа-
листов для управления и четкого понимания его влияния на производительность
и сложность системы. Следовательно, прежде чем принимать решение о реализации
сервисной сетки, необходимо оценить специфические потребности приложения
и сравнить потенциальную выгоду с возможным повышением инфраструктурной
сложности. Такой осторожный подход гарантирует, что преимущества использо-
вания сервисной сетки будут соответствовать требованиям приложения и способ-
ности команды справиться с дополнительной сложностью.
Рассмотрим подробнее AWS Арр Mesh — инструмент, нормализующий комму-
никации между сервисами и обеспечивающий всесторонний мониторинг и по-
стоянную доступность. На рис. 5.6 представлена реализация паттерна Service
mesh с использованием облачных сервисов AWS.
Как показано на диаграмме, Amazon Fargate работает как бессерверный ме-
ханизм для контейнерных вычислений, совместимый с Amazon ECS (Elastic
Container Service) и Amazon EKS (Amazon Elastic Kubernetes Service). Ниже
перечислены основные этапы реализации приложения интернет-магазина под
управлением Арр Mesh.
1. Создание сервисов Fargate: определение каждого микросервиса (пользо-
ватели, заказы, платежи, каталог товаров и аутентификация) как Amazon
Fargate в EKS с необходимыми формулировками задач.
Микросервисная архитектура 221
2. Создание AWS Арр Mesh: создание сетки, которая служит логической гра-
ницей для сетевого трафика между сервисами.
3. Определение виртуальных узлов: создание виртуального узла для каждого
сервиса ECS в Арр Mesh. Виртуальный узел служит логическим указателем
на конкретный сервис ECS.
4. Создание виртуальных маршрутизаторов и маршрутов: определение вир-
туальных маршрутизаторов и маршрутов для управления потоком трафика
между виртуальными узлами.
5. Конфигурация виртуальных сервисов: виртуальные сервисы маршрутизи-
руют трафик к виртуальным узлам, делая возможным обнаружение сервисов
в сетке.
6. Развертывание вспомогательных прокси-серверов: присоединение прок-
си-сервер Envoy к определению каждой задачи ECS как вспомогательного
контейнера. Прокси-серверы Envoy перехватывают трафик между микро-
сервисами и управляют им.
7. Мониторинг и ведение журнала: использование AWS CloudWatch и AWS
X-Ray для мониторинга и ведения журнала трафика, проходящего через сетку.
AWS X-Ray
Amazon CloudWa Ich
AWS Identity and Access Management (IAM)
Рис. 5.6. Приложение интернет-магазина под управлением Арр Mesh в AWS
Реализация сервисной сетки может улучшить межсервисные коммуникации, без-
опасность и наблюдаемость. Этот подход позволяет более эффективно управлять
микросервисной архитектурой, обеспечивая надежность и масштабируемость
222 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
сложных приложений. Восстановление после сбоев — важное условие построе-
ния крупномасштабных архитектур. Познакомимся поближе с реактивными
архитектурами, которые помогут в решении этой проблемы.
Реактивная архитектура
Поскольку облачная архитектура может иметь подвижные части из-за множе-
ства микросервисов и небольших модулей, их необходимо защищать от сбоев.
Реактивная архитектура — метод проектирования для построения продуктов,
которые могут эффективно справляться с изменениями и оставаться отзыв-
чивыми в различных условиях. Она хорошо подходит для крупномасштабных
и распределенных систем, которые должны обеспечивать высокую доступность
и отзывчивость даже при возникновении сбоев или высокой нагрузке.
Принципы реактивной архитектуры базируются на Реактивном манифесте
(или Манифесте реактивных систем) — документе, описывающем основные
характеристики реактивных систем: отзывчивость, устойчивость, эластичность
и управление посредством обмена сообщениями. Подробнее о Реактивном ма-
нифесте можно узнать на сайте https://www.reactivemanifesto.org/.
• Отзывчивость: приоритетное свойство реактивных систем — быстрая реак-
ция на запросы пользователя независимо от загруженности или состояния
системы.
• Устойчивость: реактивные системы проектируются с расчетом щадящей
обработки отказов. Они могут быстро восстанавливать работоспособность
и действовать даже при отказе некоторых компонентов.
• Эластичность: реактивные системы могут масштабироваться в зависимости
от потребностей, эффективно используя ресурсы и обеспечивая отзывчивость
при разных рабочих нагрузках.
• Обмен сообщениями: в реактивных системах компоненты взаимодействуют
с использованием асинхронно передаваемых сообщений. Такой подход делает
возможным слабую связанность компонентов, их независимую изоляцию
и доступность из разных местоположений.
Стиль реактивной архитектуры в значительной мере зависит от микросервисов,
которые сегментируют функциональность на меньшие, независимо масштаби-
руемые системы для улучшения масштабируемости, удобства обслуживания
и ускорения циклов развертывания. Коммуникации в реактивных системах
управляются событиями. Это означает, что компоненты взаимодействуют
и реагируют при помощи асинхронных событий; таким образом обеспечивается
более эффективное использование ресурсов и повышается производительность
системы.
Для управления данными реактивные архитектуры применяют децентрализо-
ванный подход, когда каждый микросервис управляет своими данными, сокра-
щая зависимости и конкуренцию за общие ресурсы. Тем самым повышается не
Реактивная архитектура 223
только устойчивость системы, но и ее способность быстро восстанавливаться
после сбоев. Изоляция и автономность занимают центральное место в реактив-
ных системах. Они гарантируют, что отказ одних компонентов не повлияет на
работу других и доступность системы в целом, а это повышает отказоустойчи-
вость системы.
Масштабируемость обеспечивается горизонтально, когда для обработки повы-
шенной нагрузки система расширяется за счет добавления новых экземпляров
сервисов вместо увеличения мощности существующих экземпляров.
Кроме того, реактивные архитектуры реализуют различные паттерны устойчиво-
сти: переключатели, тайм-ауты и повторные попытки. Эти механизмы помогают
управлять сбоями и восстанавливаться после них, не позволяя проблемам одного
компонента распространиться на всю систему. Совместно эти принципы упро-
щают создание отказоустойчивых, отзывчивых систем, способных сокращать
свою функциональность под нагрузкой постепенно.
Реактивные архитектуры особенно полезны в крупномасштабных распреде-
ленных системах, которые должны справляться с разными нагрузками, быстро
восстанавливаться после сбоев и быстро реагировать на запросы пользователя.
Представьте игровую платформу, на которой тысячи игроков одновременно
взаимодействуют с виртуальными мирами. Применение реактивной архитек-
туры позволит обеспечить плавные игровые взаимодействия и быстрый отклик.
• Отзывчивость: система быстро реагирует на действия игроков, позволяя пер-
сонажам двигаться, кастовать (применять заклинания) и взаимодействовать
с объектами в реальном времени.
• Устойчивость: если сервер внезапно упадет по техническим причинам, архи-
тектура автоматически перенаправит нагрузку на работоспособные серверы,
обеспечивая непрерывный геймплей для других игроков.
• Эластичность: по мере того как в пиковые периоды в игре участвует все боль-
ше игроков, архитектура динамически выделяет дополнительные серверные
ресурсы для обработки повышенной нагрузки. С уменьшением количества
игроков лишние ресурсы освобождаются для экономии затрат.
• Обмен сообщениями: действия игроков (кастование, покупка предметов
и т. д.) передаются через сообщения. Асинхронные коммуникации сводят
к минимуму «узкие места» и обеспечивают плавность геймплея, несмотря
на множество параллельно выполняемых действий.
Реализовать реактивную архитектуру можно по следующей схеме.
• Спроектировать компоненты для асинхронных взаимодействий с использо-
ванием очередей сообщений. Таким образом предотвращается блокирование
и улучшается быстрота реакции.
• Реализовать модель акторов, в которой компоненты (акторы) взаимодей-
ствуют посредством сообщений. Каждый актор обрабатывает сообщения
последовательно, избегая проблем с параллелизмом.
224 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
• Интегрировать паттерны устойчивости (такие, как «Предохранитель» (Circuit
Breaker) и «Переборка» (Bulkhead)) для обработки отказов и предотвраще-
ния каскадных ошибок. Эти паттерны были описаны в главе 4 «Паттерны
проектирования архитектур решений».
• Использовать механизмы автомасштабирования для динамического вы-
деления ресурсов в зависимости от нагрузки. Облачные платформы (такие,
как AWS) предоставляют средства для этой цели.
• Использовать реактивные библиотеки или фреймворки (такие, как Akka,
Spring Web Flux или ReactiveX), предоставляющие абстракции для построе-
ния реактивных систем.
Посмотрим, как реализовать реактивную архитектуру на базе сервисов AWS для
решения задачи трекинга рекламных взаимодействий. На рис. 5.7 изображена
реактивная архитектура для ad-tech компании1.
Обновления
базовых данных
Рис. 5.7. Базовая архитектура приложения для трекинга рекламы
На диаграмме изображена архитектура приложения по трекингу рекламы на
базе архитектуры AWS — как для обработки в реальном времени, так и для
пакетной обработки.
Когда пользователь просматривает рекламу или кликает по ней, баланси-
ровщик нагрузки приложения перехватывает запрос и перенаправляет его
1 Ad-tech компания — технологическая компания, которая разрабатывает решения для
цифровой рекламы. — Примеч. ред.
Архитектура на базе очереди 225
соответствующему сервису в основном приложении. Приложение независимо
обрабатывает каждый запрос, своевременно и надежно, но без немедленной
записи в базу данных. Вместо этого Amazon Kinesis Data Streams собирает эти
события, а функция AWS Lambda обеспечивает запись информации в таблицу
Amazon DynamoDB. Amazon Kinesis Data Streams — высокомасштабируемый
и надежный сервис потоковой передачи данных в реальном времени, предназна-
ченный для сбора, обработки и анализа потоковых данных. Такая конфигурация
потоков данных выполняет функции защитного посредника, гарантируя, что
данные не будут потеряны за периоды высокого трафика.
Чтобы оптимизировать скорость доступа к критическим данным, Amazon
ElastiCache для Redis используется в качестве первичного кэша. Обновления
основных данных синхронизируются через архитектуру передачи сообщений,
при этом потоки событий используются для обнаружения и передачи изменений
из всех систем-участников. Такая организация позволяет обрабатывать пере-
менные объемы запросов, при этом функции Lambda обрабатывают потоковые
данные и обновляют первичный кэш для обеспечения целостности и произво-
дительности системы.
Интеграция этих сервисов AWS позволяет построить реактивную архитектуру
для рекламной платформы. Сервисы, предоставляемые AWS, соответствуют
базовым принципам отзывчивости, устойчивости, эластичности и обмена со-
общениями, которые определяют реактивную систему.
Слабосвязанная архитектура играет ключевую роль в построении легко мас-
штабируемых облачно-ориентированных архитектур, для чего важны очереди
сообщений. Давайте поближе познакомимся с архитектурными паттернами на
базе очередей.
Архитектура на базе очереди
В предыдущем разделе вы узнали о проектировании микросервисов с примене-
нием RESTful-архитектуры. Такая архитектура упрощает обнаружение микро-
сервисов, но что, если сервис выйдет из строя? В модели RESTful клиентский
сервис ожидает ответа от ведущего сервиса; это означает, что запрос HTTP
блокирует API. Иногда информация может теряться из-за недоступности ниже-
лежащего сервиса. Для сохранения информации в таких случаях необходимо
реализовать логику повторных попыток (retry).
Архитектура на базе очереди решает эту проблему добавлением очередей сообще-
ний между сервисами; эти сообщения хранят информацию от имени сервисов.
Архитектура на базе очереди предоставляет полностью асинхронные коммуни-
кации, она слабо связана. В такой архитектуре информация остается доступной
в сообщении. Если сервер выйдет из строя, сообщение будет обработано, как
только сервис станет доступным.
226 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Познакомимся с терминологией архитектуры на базе очереди.
• Сообщение: состоит из двух частей — заголовка и тела. Заголовок содержит
метаданные, относящиеся к сообщению, а тело — собственно сообщение.
• Очередь: содержит сообщения, которые могут использоваться при необхо-
димости.
• Производитель: сервис, производящий и публикующий сообщение в очереди.
• Потребитель: сервис, потребляющий сообщения.
• Брокер сообщений: помогает собирать, маршрутизировать и распределять
сообщения между производителем и потребителем.
Рассмотрим некоторые типичные архитектурные паттерны на базе очереди,
чтобы понять, как они работают.
Паттерн Queuing Chain (Цепочка очередей)
Паттерн «Цепочка очередей» применяется в ситуации, когда последовательная
обработка должна выполняться на нескольких связанных системах. Рассмотрим
его применение на примере приложения для обработки изображений. В пай-
плайне обработки графики последовательные операции — захват изображения,
сохранение его на сервере, запуск задания для создания копий изображения
в разном разрешении, нанесение водяных знаков и генерирование миниатюр —
тесно связаны друг с другом. Сбой в одной части может привести к нарушению
всей операции.
Можно использовать очереди между разными системами и заданиями, чтобы
устранить единую точку сбоя и спроектировать по-настоящему слабосвязан-
ную систему. Паттерн «Цепочка очередей» позволяет связать разные системы
и увеличивает количество серверов, которые могут обрабатывать сообщения
параллельно. Чтобы завершить работу лишних серверов при отсутствии изо-
бражений для обработки, можно настроить автомасштабирование.
На рис. 5.8 показана архитектура паттерна «Цепочка очередей» для приложения
из рассматриваемого примера. Здесь очередь, предоставляемая AWS, называется
Amazon SQS (Simple Queue Service).
Изображенная архитектура включает следующие этапы.
1. Когда на сервер загружается необработанное изображение, приложение
должно пометить все изображения водяным знаком с логотипом компании.
Парк серверов Amazon ЕС2 (Elastic Cloud Compute) запускает пакетные за-
дания для нанесения водяных знаков и помещает обработанное изображение
в очередь Amazon SQS.
2. Второй парк серверов Amazon ЕС2 загружает изображения с водяными
знаками из очереди Amazon SQS.
3. Второй парк воркеров ЕС2 обрабатывает изображение и создает его варианты
с разными разрешениями.
Архитектура на базе очереди 227
4. После кодирования изображений воркеры ЕС2 отправляют сообщение
в другую очередь Amazon SQL для создания миниатюр.
5. После обработки изображения задание удаляет сообщение из предыдущей
очереди для освобождения места.
6. Последний парк серверов ЕС2 получает закодированные сообщения из оче-
реди и создает миниатюры вместе с метками авторского права.
задания
Облако AWS
Рис. 5.8. Архитектура паттерна «Цепочка очередей»
Такая архитектура имеет следующие преимущества.
• Возможность использовать слабосвязанную асинхронную обработку, чтобы
быстро возвращать ответы, не ожидая подтверждения от другого сервиса.
• Систему можно структурировать слабым связыванием экземпляров Amazon
ЕС2 или контейнеров с использованием Amazon SQS.
• Сообщение в сервисе очереди остается даже при возникновении сбоя в эк-
земпляре Amazon ЕС2. Этот факт очень важен для поддержания целостности
данных и отказоустойчивости системы, так как он гарантирует, что обра-
ботка будет возобновлена, когда сервер снова станет работоспособен. Такая
архитектура создает устойчивую систему, которая способна пережить сбой
сервера и восстановиться без потери критических данных.
Вы можете столкнуться с колебаниями нагрузки на приложение, которые способ-
ны привести к непредвиденным нагрузкам сообщений. Автоматизация рабочей
нагрузки с использованием паттерна «Цепочка очередей» поможет справиться
с любыми колебаниями. Давайте узнаем больше о применении в таких ситуациях
паттерна Job Observer (Наблюдатель заданий).
228 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Паттерн Job Observer (Наблюдатель заданий)
Паттерн «Цепочка очередей» помогает спроектировать слабосвязанную архитек-
туру, но что делать с выбросами рабочей нагрузки? При колебании количества
запросов необходимо регулировать вычислительные мощности в зависимости
от потребностей пользователей; в этом может помочь паттерн Job Oserver «На-
блюдатель заданий».
В паттерне «Наблюдатель заданий» можно создать группу автомасштабирования
на основании количества сообщений, ожидающих обработки в очереди. Паттерн
помогает поддерживать производительность за счет увеличения или уменьше-
ния количества экземпляров серверов, используемых при обработке задания.
На рис. 5.9 изображена архитектура этого паттерна.
Очередь сообщений
Рис. 5.9. Архитектура паттерна Job Observer («Наблюдатель заданий»)
На представленной диаграмме первый парк серверов Amazon ЕС2 (слева) выпол-
няет пакетные задания и помещает сообщения в очередь (например, метаданные
изображений). Второй парк серверов ЕС2 (справа) потребляет и обрабатывает
эти сообщения — например, при кодировании изображений. Когда количество
сообщений достигает определенного порога, Amazon Cloud Watch инициирует
автомасштабирование, чтобы включить дополнительный сервер в парк потреби-
телей для ускорения обработки заданий. Автомасштабирование также удаляет
лишние серверы, когда величина очереди падает ниже порога.
Вычисления в паттерне «Наблюдатель заданий» масштабируются по размеру
задания, обеспечивая эффективность и экономию затрат. Архитектура паттерна
Архитектура Pipes-and-Filters (Каналы и фильтры)
229
обеспечивает быстрое завершение задания. Процесс является устойчивым, это
означает, что обработка задания не прерывается в случае сбоя сервера.
Хотя архитектура на базе очереди обеспечивает слабую связанность, она работает
в основном по асинхронному pull-методу, когда потребитель может извлекать
сообщения из очереди при их появлении.
В облачно-ориентированных архитектурах бывает полезно добавить небольшие
независимые шаги между архитектурными компонентами, когда одно событие
должно инициировать другие события. Чтобы реализовать такую схему, рас-
смотрим архитектуру Pipes-and-Filters (Каналы и фильтры).
Архитектура Pipes-and-Filters
(Каналы и фильтры)
Архитектура «Каналы и фильтры» — паттерн проектирования, который делит
сложные задачи на серию стадий, то есть меньших независимых этапов об-
работки. На каждой стадии выполняется определенная операция с входными
данными и преобразованные данные передаются на следующую стадию через
так называемый канал (pipe). Стадии называются фильтрами (filters), а связи
между ними — каналами. Давайте взглянем поближе на основные компоненты
этой архитектуры.
• Фильтры — блоки, выполняющие определенные операции с данными.
Фильтры читают входные данные, обрабатывают их и производят выходные
данные. Каждый фильтр работает независимо от других и может разрабаты-
ваться и тестироваться отдельно.
• Каналы — связи, по которым передаются данные между фильтрами. Это могут
быть простые потоки данных или более сложные механизмы — например,
очереди сообщений с буферизацией, синхронизацией и преобразованиями
формата данных.
Основное преимущество этого архитектурного паттерна — надежная структура,
которая способствует разделению ответственности и модульности, упрощая по-
нимание, изменение и обслуживание сложных систем. Его ценят за возможности
повторного использования, компоновки, последовательную обработку и масшта-
бируемость. Отдельные фильтры, которые выполняют задачи обработки, могут
повторно использоваться в разных приложениях, обеспечивая согласованность
поведения и сокращая время разработки. Компоновка фильтров позволяет
создавать сложные цепочки обработки, которые можно легко изменять, меняя
фильтры местами по мере необходимости.
Данные передаются по каналам четко и последовательно, что дает возможность
каждому фильтру преобразовывать данные шаг за шагом, упрощая понимание
и обслуживание системы. Кроме того, паттерн поддерживает масштабируе-
мость, так как фильтры могут работать параллельно и распределяться между
230 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
несколькими вычислительными узлами, чтобы система эффективно справлялась
с возрастающей рабочей нагрузкой.
Пример поможет понять суть этой схемы. Представьте пайплайн обработки текста,
который читает текстовый файл, удаляет из него стоп-слова, осуществляет стем-
минг (усечение слова до его основы) и подсчитывает вхождения каждого слова.
Эту задачу можно решить с применением архитектуры «Каналы и фильтры».
1. Фильтр 1 — чтение файла: читает текстовый файл и выводит строки текста.
2. Фильтр 2 — разбиение: разбивает строки на отдельные слова.
3. Фильтр 3 — удаление стоп-слов: удаляет такие служебные слова, как «and»,
«the», «is» и т. д.
4. Фильтр 4 — стемминг, то есть выделение основ: усекает слово до его основы
(например, «walking» до «walk»).
5. Фильтр 5 — подсчет слов: подсчитывает число вхождений каждого слова.
Фильтры соединяются каналами, по которым передаются данные между ними.
Пайплайн читает текстовый файл, обрабатывает его шаг за шагом и выводит
частоту отдельных слов.
Архитектура «Каналы и фильтры» — мощный паттерн проектирования для
построения модульных и легко расширяемых систем. Архитекторы могут
создавать гибкие, простые в обслуживании и масштабируемые приложения
путем разбиения сложных задач на серию меньших независимых фильтров,
соединенных каналами.
Теперь пора узнать больше об архитектуре, управляемой событиями (EDA,
Event-Driven Architecture), — парадигме проектирования, в которой после-
довательность выполнения программы определяется событиями (например,
действиями пользователей или сообщениями от других программ). Эти собы-
тия обрабатываются асинхронно независимыми компонентами, что позволяет
системам поддерживать высокую отзывчивость и адаптироваться к изменениям
или колебаниям рабочей нагрузки.
Архитектура, управляемая событиями
Когда архитектура, управляемая событиями, реализуется в рамках облачно-
ориентированной архитектуры, она улучшает способность системы реагировать
на данные реального времени и события. Эта комбинация способна приводить
к построению высокоэффективных, масштабируемых систем, быстро реагиру-
ющих на изменения. Облачно-ориентированная среда поддерживает динами-
ческое распределение ресурсов, чтобы справляться с переменными нагрузками
событийных систем, а архитектура, управляемая событиями, предоставляет
механизм быстрой и реактивной обработки.
Архитектура, управляемая событиями, помогает создать цепочку событий
для завершения функционального потока. Например, когда вы совершаете
Архитектура, управляемая событиями 231
платеж за покупку в интернет-магазине, вы ожидаете, что сразу же после
завершения платежа будет сгенерирован чек и вы получите его по электрон-
ной почте. Архитектура, управляемая событиями, помогает связать все эти
события в цепочку, чтобы оплата инициировала другую задачу для заверше-
ния процесса. Часто очереди сообщений, о которых вы узнали в предыдущем
разделе, становятся центром архитектуры, управляемой событиями. Такие
архитектуры также могут базироваться на модели «издатель/подписчик» или
модели потока событий.
Модель Publisher/subscriber (Издатель/подписчик)
В модели «Издатель/подписчик» (publisher/subscriber, или pub/sub) при
публикации события всем подписчикам отправляется уведомление, и каждый
подписчик выполняет действия, определяемые требованиями к обработке
данных.
Возьмем в качестве примера приложение для обработки фотографий, которое
дополняет фотографии фильтрами и отправляет уведомление пользователю.
Соответствующая модель «Издатель/подписчик» изображена на рис. 5.10.
Приложение для
отправки фотографий
пользователя
Рис. 5.10. Приложение для обработки фотографий с событийной архитектурой
«Издатель/подписчик» (pub/sub)
На этой диаграмме стоит обратить внимание на следующие особенности.
1. Пользователь сначала отправляет фотографию в ячейку Amazon S3 из веб-
или мобильного приложения.
2. Ячейка Amazon S3 отправляет уведомление сервису Amazon SNS (Simple
Notification Service). Amazon SNS предоставляет топик сообщений с не-
сколькими подписчиками.
Первый подписчик использует сервис электронной почты, и сразу же
после завершения загрузки фотографии пользователю отправляется со-
общение электронной почты.
232 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Второй подписчик использует очередь Amazon SQS, которая получает со-
общение из топика Amazon SNS и применяет фильтры в коде, написанном
в AWS Lambda, для повышения качества изображения.
Третий подписчик использует функцию AWS Lambda, которая генерирует
миниатюру изображения.
В этой архитектуре Amazon S3 как производитель (producer) публикует сообще-
ние в топике SNS, которая потребляется несколькими подписчиками. Кроме того,
как только сообщение поступает в SQS, оно инициирует событие для функции
Lambda, обрабатывающей изображения.
Модель Event stream (Поток событий)
В этой модели потребитель может читать непрерывный поток событий от про-
изводителя. Например, поток событий может использоваться для перехвата не-
прерывного потока журнала истории посещений, а также отправки оповещений
при выявлении аномалий, как показано на рис. 5.11.
Данные посещений
от разных
пользователей
Определение эффективности
рекламы Anomalies — Аномалии
Kinesis Data Kinesis Data Kinesis Data
Stream Analytics
Firehose
HTTP-уведомление Уведомление
других сервисов по электронной
почте
Amazon S3
Рис. 5.11. Журнал истории посещений в архитектуре потока событий
Amazon Kinesis — сервис, используемый для поглощения, обработки и сохра-
нения непрерывных потоковых данных. На диаграмме разные пользователи,
совершающие клики в мобильных и веб-версиях приложений интернет-мага-
зинов, генерируют поток событий.
События посещений отправляются приложениям аналитики с использованием
шлюза Amazon API Gateway для проведения аналитики в реальном времени.
В приложении аналитики Amazon Kinesis Data Analytics вычисляются пока-
затели конверсии — например, количество человек, сделавших покупку за по-
следние пять минут. После агрегирования данных в реальном времени Amazon
Kinesis Data Analytics отправляет результаты сервису Amazon Kinesis Data
Архитектура, управляемая событиями 233
Firehose, который сохраняет все файлы данных в хранилище Amazon S3 для
дальнейшей обработки.
Функция Lambda читает данные из потока событий и начинает проверять их на
наличие аномалий. При обнаружении аномалий в метриках конверсии функция
AWS Lambda отправляет уведомление по электронной почте рекламному от-
делу. В этой архитектуре поток событий непрерывен, a AWS Lambda читает из
него данные, относящиеся к конкретному событию.
В модели EDA производители и потребители работают независимо, а события
выступают в роли коммуникационной среды. Такое деление означает, что про-
изводители могут отправлять события, не зная, какие потребители будут их
обрабатывать, а потребители могут прослушивать интересующие их события, не
зная, кто их произвел. Такой подход приводит к созданию гибкой и расширяемой
системы, в которую могут добавляться новые потребители для обработки собы-
тий без изменения существующих производителей; это расширяет возможности
масштабирования и адаптируемости. Тем не менее наряду с преимуществами
архитектура, управляемая событиями, подразумевает и проблемы, которые
придется решать.
• Предотвращение повторяющейся обработки: в распределенных системах
одно событие может доставляться многократно из-за повторных попыток
передачи по сети или выхода сервисов из строя. Реализация идемпотентности
в потребителях событий гарантирует, что многократная обработка события
не приведет к некорректному поведению или несогласованности данных.
• Обработка сообщений об ошибках: надежно спроектированная архитек-
тура EDA должна иметь эффективный механизм обработки ошибок. Он
может включать очередь недоставленных сообщений, в которых события
не могут обрабатываться и хранятся для последующего анализа или по-
вторных попыток, а также логику обработки ошибок в потребителях, ко-
торая будет управлять исключениями без нарушения работоспособности
всей системы.
• Упорядочение событий: обработка событий в правильном порядке может
быть очень важна. При этом могут использоваться паттерны упорядочения
или механизм порождения событий для поддержания порядка для каждой
сущности.
• Отслеживание и мониторинг событий: по мере масштабирования системы
становится важно отслеживать поток событий и проводить мониторинг
работоспособности системы. Правильная реализация механизмов ведения
журнала, трассировки и оповещения позволяет получить информацию о ра-
боте системы и проводить быструю диагностику проблем.
• Управление схемой событий: по мере эволюции системы схемы событий
могут изменяться. Управление этими изменениями без нарушения работо-
способности системы требует создания реестра схем и стратегии управления
версиями, чтобы потребители правильно понимали разные версии событий.
234 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Хотя архитектура, управляемая событиями, облегчает масштабируемость и рас-
ширяемость, она требует тщательного проектирования с учетом особенностей
эксплуатации, чтобы обеспечить устойчивость, согласованность и удобство
обслуживания системы.
В модульной архитектуре для достижения полноценной масштабируемости
очень важно обеспечить модульность на всех архитектурных уровнях. Перейдем
к рассмотрению паттерна проектирования BFF, который служит для соблюдения
этого принципа.
Паттерн BFF (Backend for Frontend)
Паттерн BFF (Backend for Frontend, то есть бэкенд для фронтенда) — облач-
но-ориентированный архитектурный паттерн, который адаптирует сервисы
бэкенда для каждой конкретной разновидности фронтенд-приложений. Пат-
терн BFF появился в ответ на растущую сложность современных мобильных
и веб-приложений. Он подразумевает создание разных сервисов бэкенда, адап-
тированных для каждого фронтенда или взаимодействия с пользователем. Тем
самым BFF упрощает фронтенд-разработку и оптимизирует ответы бэкенда
к уникальным требованиям каждого фронтенда.
Кратко охарактеризуем основные особенности паттерна BFF.
• Адаптированные API: каждый фронтенд (например, веб-приложение, мо-
бильное приложение, смарт-ТВ) имеет собственный бэкенд-сервис (BFF),
адаптированный для своих специфических потребностей. BFF предоставляют
API, которые поставляют только данные, необходимые фронтенду, в под-
ходящем формате. Такой подход сокращает необходимость преобразования
данных на фронтенде и приводит к оптимизации ответов API.
• Упрощение фронтенд-разработки: фронтенд-разработчики могут актив-
но использовать BFF для повышения эффективности совместной работы
и ускорения циклов разработки. Реализации BFF можно писать на том же
языке, что и фронтенд; это поможет фронтенд-разработчикам понять и из-
менить бэкенд.
• Делегирование сложности: BFF могут решать задачи, которыми в противном
случае занимался бы фронтенд: аутентификацию, агрегирование данных и об-
работку ошибок. Делегирование сложности сокращает рабочую нагрузку на
фронтенд и повышает качество пользовательских взаимодействий.
• Независимое развитие: каждый сервис BFF может развиваться независимо,
что упростит развертывание обновлений и функциональности для конкрет-
ных фронтендов без последствий для других. BFF работают как адаптеры
между фронтендами и базовыми бэкенд-сервисами, сводя к минимуму
влияние изменений на каждом уровне.
Рассмотрим приложение интернет-магазина с фронтендами для веб-приложений,
мобильных приложений и смарт-ТВ.
Облачно-ориентированные архитектурные антипаттерны 235
• BFF для веб: предоставляет подробные описания товаров, отзывы пользова-
телей и рекомендации для веб-фронтенда. Агрегирует данные от нескольких
бэкенд-сервисов (информацию о товарах, пользовательские профили, ре-
комендательные системы). Преобразует данные в формат, пригодный для
отображения в веб-браузерах.
• Мобильный BFF: предоставляет упрощенные описания товаров, отзывы
пользователей и рекомендации, оптимизированные для мобильных устройств.
Решает такие задачи, как масштабирование изображений для меньших экра-
нов. Агрегирует данные и адаптирует их для специфических потребностей
мобильного фронтенда.
• BFF для смарт-ТВ: предоставляет информацию о товарах, отзывы пользо-
вателей и рекомендации, адаптированные для больших экранов смарт-ТВ.
Преобразует данные для больших экранов и предоставляет упрощенные
средства навигации. Агрегирует данные и адаптирует их для требований
фронтенда смарт-ТВ.
Имея отдельный BFF для каждого фронтенда, приложение интернет-магазина
может предоставить оптимизированные пользовательские взаимодействия на
разных платформах, одновременно упрощая разработку фронтенда и сокращая
сложность сервисов бэкенда.
Паттерн проектирования BFF эффективен при построении современных мобиль-
ных и веб-приложений: он предлагает такие возможности, как адаптированные
API, упрощенная разработка фронтенда, делегирование сложности и независи-
мое развитие. Архитекторы используют BFF для создания более эффективных,
отзывчивых и удобных для пользователя приложений на разных платформах.
Мы рассмотрели паттерны проектирования облачно-ориентированных архитек-
тур. Теперь познакомимся с некоторыми антипаттернами, которых необходимо
избегать.
Облачно-ориентированные архитектурные
антипаттерны
В облачно-ориентированных архитектурах, как и в любых системных архитек-
турах, некоторые практики считаются антипаттернами. Антипаттерн — метод,
который на первый взгляд кажется полезным, но обычно не оправдывает ожи-
даний и даже может отрицательно сказаться на приложении. Ниже описаны
некоторые распространенные антипаттерны, которых следует избегать в об-
лачно-ориентированных архитектурах.
Единая точка сбоя
Единая точка сбоя возникает, когда сбой отдельного компонента может
вывести из строя всю систему. Проектируйте облачно-ориентированную
архитектуру с избыточностью и механизмами обработки отказов, чтобы такие
236 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
сбои обрабатывались корректно. Облачное приложение, зависящее от одного
экземпляра базы данных без резервных копий или репликации, подвержено
общесистемным сбоям в случае выхода из строя этого экземпляра. Реализация
избыточной конфигурации базы данных с репликацией и автоматической об-
работкой отказов предотвращает этот сценарий.
Ручное масштабирование
Ручное масштабирование подразумевает ручное добавление или удаление
ресурсов в зависимости от изменяющейся потребности. Это может быть долго,
ненадежно и неэффективно. Используйте бессерверный сервис и средства
автомасштабирования, которые автоматически корректируют количество ра-
ботающих экземпляров в зависимости от потребности.
Если потоковый сервис сталкивается с внезапным пиком просмотров (например,
во время популярного мероприятия), ручное масштабирование инфраструктуры
может оказаться недостаточно быстрым. Использование бессерверных сервисов
или автомасштабирования позволяет сервису быстро добрать необходимые ре-
сурсы для удовлетворения спроса или освободить ресурсы после его снижения.
Сильносвязанные сервисы
В микросервисной архитектуре сервисы должны быть слабо связаны, чтобы они
могли работать независимо. Сильная связанность может привести к хрупкости
системы, когда ее обслуживание и развитие сильно затруднены. Например, если
сервис оплаты и сервис доставки в интернет-магазине сильно связаны, изменения
в одном сервисе могут непреднамеренно повлиять на другой. Проектирование
этих сервисов с четкими границами и API позволяет им эволюционировать
независимо.
Игнорирование лучших практик безопасности
Безопасность должна быть приоритетом в любой облачно-ориентированной
архитектуре. Если разработчик будет игнорировать лучшие практики безопас-
ности, это может привести к взлому, несанкционированному доступу и другим
инцидентам безопасности. Приложение, хранящее пользовательские пароли
в виде простого текста, уязвимо для взлома. Правильная реализация хеширова-
ния паролей, добавление соли и другие меры безопасности могут предотвратить
такие инциденты.
Отсутствие мониторинга или ведения журналов
Мониторинг и ведение журналов необходимы для диагностики проблем, оп-
тимизации производительности и понимания поведения системы. Реализуйте
средства мониторинга, чтобы отслеживать работоспособность приложения,
и журналы для диагностики проблем. Если облачное приложение сталкивается
Облачно-ориентированные архитектурные антипаттерны 237
с проблемами производительности, подробные данные мониторинга и журналы
могут помочь с выявлением проблемы — например, увеличения сетевой задерж-
ки, ограничений ресурсов или ошибок приложений.
Игнорирование сетевой задержки
Сетевая задержка может влиять на производительность приложений в рас-
пределенных системах. Проектируйте приложение так, чтобы оно корректно
обрабатывало сетевую задержку. Например, в интернет-магазине на базе микро-
сервисов сетевая задержка между сервисами может замедлить пользователь-
ские взаимодействия, в частности просмотр товаров или оформление заказа.
Реализация таких мер, как кэширование, репликация данных и асинхронные
взаимодействия, может компенсировать сетевую задержку.
Недостаточное тестирование
Правильно организованное тестирование помогает приложениям функциониро-
вать как задумано и выявлять проблемы до того, как они появятся на продакшен.
Облачно-ориентированное приложение, обрабатывающее пользовательские
данные, должно включать разнообразные модульные, интеграционные и сквоз-
ные тесты для проверки правильности обработки данных, предотвращения по-
тери или повреждения данных или проверки правильности интеграции между
сервисами.
Чрезмерная оптимизация
Чрезмерная и преждевременная оптимизация приложений может усложнить
код и затруднить его обслуживание. Реализация высокооптимизированной
специализированной структуры данных для облачного приложения может
слегка повысить производительность, но при этом усложнить понимание кода,
его поддержку и адаптацию к будущим изменениям.
Игнорирование затрат
Облачные сервисы могут быть весьма затратными при неправильном управле-
нии. Обеспечьте мониторинг и оптимизируйте использование облачных ресур-
сов, чтобы избежать непредвиденных затрат. Например, выполнение больших
экземпляров в режиме 24/7 для приложения с переменной нагрузкой может
обойтись достаточно дорого. Реализация автомасштабирования и использование
бессерверных сервисов позволяют оптимизировать затраты за счет корректи-
ровки по текущей потребности.
Если вы избежите антипаттернов, то сможете создать надежную, масштабируе-
мую и легко обслуживаемую облачно-ориентированную архитектуру. Следуя
лучшим практикам, избегая перечисленных антипаттернов и используя ре-
шения с микросервисами, можно обеспечить масштабируемость, надежность
238 Глава 5. Паттерны проектирования облачно-ориентированных архитектур
и безопасность облачных приложений. В процессе построения и эволюции
приложений не забывайте о потенциальных проблемах и старайтесь постоянно
совершенствовать архитектуру, операции и стратегии мониторинга.
Итоги
В этой главе были подробно рассмотрены облачно-ориентированные архитек-
туры, представлены важнейшие концепции, паттерны и практики, которых
необходимо придерживаться, чтобы создавать устойчивые, масштабируемые
и эффективные системы.
Мы начали с рассмотрения сути облачно-ориентированной архитектуры и ее
потенциала для современной разработки ПО. Вы узнали об основных пре-
имуществах этой архитектуры, включая масштабируемость, устойчивость
и адаптивность, которые делают ее необходимой в динамичной современной
среде разработки.
Мы глубоко изучили бессерверную архитектуру и выяснили, как она обеспечи-
вает экономию средств, гладкую масштабируемость и простоту эксплуатации.
Вы узнали о различиях и нюансах архитектур с сохранением состояния и без
сохранения состояния, соответствующих сценариях использования и стратегиях
реализации. Мы заглянули в область микросервисных архитектур и исследо-
вали их преимущества: масштабируемость, отказоустойчивость и простоту
развертывания.
Вы познакомились с паттерном Saga (Сага), получили представление о его
использовании для управления продолжительными транзакциями и узнали
о факторах его эффективной реализации. В главе был также представлен пат-
терн Fan-out/fan-in, вы узнали о его возможностях для параллельной обработки
и последующего агрегирования данных. Далее был рассмотрен паттерн Service
mesh (Сервисная сетка) с описанием его вклада в децентрализацию управления
сервисами, улучшение наблюдаемости и управление трафиком.
Мы рассмотрели реактивную архитектуру, ее асинхронную и управляемую со-
бытиями природу, а также раскрыли ее потенциал для улучшения отзывчиво-
сти и масштабируемости. Далее мы исследовали архитектуру на базе очередей
и представили ее преимущества для ослабления связей и асинхронной обработки.
Изучение паттерна Queuing chain (Цепочка очередей) дало представление о его
практическом применении и стратегиях создания надежных последовательных
потоков операций.
Вы познакомились с паттерном Job observer (Наблюдатель заданий) и узнали,
почему он полезен для эффективного мониторинга и управления заданиями.
Далее была рассмотрена архитектура Pipes and filters (Каналы и фильтры), и вы
узнали о ее гибкости и возможности компоновки при обработке потоков данных.
Затем мы перешли к архитектурам, управляемым событиями, и рассмотрели
их основные преимущества — масштабируемость, отзывчивость и ослабление
Итоги 239
связей. После этого были рассмотрены модель Pub/sub (Издатель/подписчик)
и ее потенциал для масштабируемых и слабосвязанных механизмов распростра-
нения событий, а также модель Event flow (Поток событий) и ее преимущества
для обработки непрерывных потоков событий.
Мы исследовали паттерн BFF и его способность адаптировать бэкенды кон-
кретных пользовательских интерфейсов для обеспечения большей гибкости
и производительности. В завершение главы мы рассмотрели распространенные
антипаттерны облачно-ориентированных архитектур; вы узнали, как избежать
этих ловушек и применять лучшие практики.
Благодаря новому пониманию облачно-ориентированных архитектур вы бу-
дете лучше подготовлены к проектированию стабильных, масштабируемых
и эффективных облачно-ориентированных систем, соответствующих вашим
специфическим требованиям и целям.
Если в этой главе рассматривались различные архитектурные паттерны, то
в следующей речь пойдет о принципах проектирования архитектур для опти-
мизации производительности. Также будет подробно рассмотрена тема выбора
технологии для вычислений, хранения, баз данных и сетей с целью улучшения
производительности приложения.
ГЛАВА 6
ФАКТОРЫ
ПРОИЗВОДИТЕЛЬНОСТИ
Эксперименты показывают, что каждая секунда задержки при загрузке прило-
жения значительно снижает доход организаций. Следовательно, производитель-
ность приложения является одним из самых важных его параметров, влияющим
на уровень принятия продукта пользователями.
В предыдущей главе обсуждались паттерны проектирования, которые могут
использоваться для решения сложных бизнес-задач. В этой главе рассматрива-
ются некоторые лучшие практики оптимизации приложений, которые следует
применять на каждом уровне и со всеми архитектурными компонентами. Вы
узнаете, как выбрать правильную технологию для разных уровней архитектуры,
чтобы непрерывно улучшать производительность приложения. Эта глава будет
посвящена следующим темам.
• Принципы проектирования высокопроизводительных архитектур.
• Выбор технологии для оптимизации производительности.
• Факторы производительности для мобильных приложений.
• Тестирование производительности.
• Мониторинг производительности.
К концу главы вы будете понимать важнейшие факторы производительно-
сти — такие, как задержка, пропускная способность и параллелизм. Вы сможете
совершать более обоснованный выбор технологии, чтобы улучшить производи-
тельность на разных уровнях архитектуры: вычисления, хранение информации,
базы данных и сетевые взаимодействия.
Принципы проектирования
высокопроизводительных архитектур
Производительность архитектуры подразумевает использование инфраструкту-
ры приложения и доступных ресурсов для удовлетворения растущих потребно-
стей и технологической эволюции. Производительность заставляет архитекторов
Принципы проектирования высокопроизводительных архитектур 241
создавать системы, которые не только отвечают текущим потребностям, но
и обладают достаточной гибкостью для масштабирования и развития, чтобы
поддерживать производительность стабильно высокой и соответствующей
ожиданиям пользователей и изменениям технологий.
Рассмотрим некоторые важные принципы проектирования для оптимизации
производительности рабочей нагрузки.
Сокращение задержки
Задержка (latency) может значительно повлиять на популярность продукта
у пользователей, потому что они предпочитают самые быстрые приложения.
Где бы ни находились пользователи, вы должны предоставить им эффективный
и надежный сервис. Задержкой называется время, необходимое для передачи
пакета данных из одной определенной точки в другую. Если выражаться проще,
это время между инициированием действия и появлением ответа на устройстве
или в системе. На задержку могут влиять разные факторы, включая физическое
расстояние между клиентом и сервером, скорость среды передачи (например,
оптоволоконный кабель или беспроводной сигнал) и занятость сети.
Представьте, что вы просматриваете веб-сайт. Когда вы кликаете на ссылке
или нажимаете кнопку, запрос передается от устройства серверу сайта. Сервер
может находиться в том же городе, что и вы, а может — на другом конце света.
Время, необходимое для того, чтобы запрос попал на сервер, тот обработал этот
запрос, а затем вернул ответ, и формирует то, что мы называем задержкой. До-
стичь нулевой задержки невозможно, но необходимо стремиться к тому, чтобы
время реакции не превышало предел ожидания пользователей.
Представьте сценарий (рис. 6.1), где передача сообщения от устройства к сер-
веру занимает 600 миллисекунд (мс); это может быть связано с физическим
расстоянием, которое должны преодолеть данные, или с тем, что пакеты
данных маршрутизируются через несколько промежуточных устройств —
маршрутизаторов, коммутаторов и т. д. Если серверу требуется еще 900 мс
для обработки запроса и отправки ответа, то общая фактическая задержка
составит 1,5 секунды (1500 мс). Этого достаточно, чтобы заметить задержку
при загрузке веб-страницы.
Клиент
900 мс
Рис. 6.1. Задержка между запросом и ответом в модели «клиент — сервер»
242 Глава 6. Факторы производительности
В наше время любому приложению необходим выход в интернет, чтобы иметь
доступ к широкой аудитории глобальных пользователей. Эти пользователи
ожидают стабильной производительности независимо от своего географического
положения. Иногда обеспечить соответствие их ожиданиям непросто, поскольку
перемещение данных по сети из одной части света в другую требует времени.
Сетевую задержку могут вызывать различные факторы, например сетевая сре-
да передачи данных, переходы маршрутизаторов и распространение сигнала.
В корпоративных средах для соединения корпоративной сети с облаком обычно
используется оптоволоконная линия, чтобы избежать несогласованности дан-
ных. Организации также могут пользоваться сетями распространения контента
(CDN) для хранения тяжелых графических и видеоданных рядом с пользо-
вателем для снижения сетевой задержки и улучшения производительности.
С периферийными ячейками проще развертывать рабочие нагрузки вблизи
пользовательской базы.
Кроме сети, задержка может возникать в компонентах архитектуры. На вычис-
лительном сервере задержка может проявляться на уровне инфраструктуры, так
как передача данных между процессором и оперативной памятью выполняется
относительно медленно. Диск может создавать задержку из-за медленных опе-
раций чтения и записи. Задержка на жестком диске (HDD) зависит от време-
ни, необходимого для выбора сектора памяти диска и для того, чтобы головка
диска совпала с выбранным сектором для чтения и записи. Дисковая память
представляет собой физическую область хранения данных на диске. На HDD
данные распределяются по секторам в ходе операций записи. Так как диск по-
стоянно вращается, данные могут распределяться по нему в непредсказуемом
порядке. В ходе операций чтения считывающая головка должна дождаться, пока
в результате вращения она окажется у нужного сектора.
На уровне базы данных задержка может вызываться медленными операциями
чтения и записи из-за «узких мест» оборудования или медленной обработки
запросов. Снижение нагрузки на базу данных за счет распределения данных
при сегментации и шардировании может уменьшить задержку.
Так как задержка и пропускная способность напрямую связаны, низкая задержка
означает повышение пропускной способности. Давайте поближе познакомимся
с этим понятием.
Повышение пропускной способности
Пропускной способностью (throughput) сети называется объем данных, кото-
рые могут быть успешно переданы по сети в определенный период времени. Эта
метрика необходима для понимания того, насколько эффективно работает сеть
при заданных условиях и нагрузке. На пропускную способность могут влиять
разные факторы, включая емкость сети, качество соединения и протоколы,
используемые для передачи данных. Емкость сети определяет максимальный
объем данных, которые могут быть переданы по ней.
Принципы проектирования высокопроизводительных архитектур 243
Пропускная способность и задержка напрямую связаны. Низкая задержка оз-
начает высокую пропускную способность, потому что больший объем данных
передается за меньшее время. Чтобы лучше понять, почему это так, воспользу-
емся аналогией с транспортной инфраструктурой страны.
Будем считать шоссе с несколькими полосами движения аналогом сетевых
каналов, а машины — аналогами пакетов данных. Представим, что 16-полосное
шоссе связывает два города. Не все машины достигают точки назначения за
нужное время: они могут задерживаться из-за пробок, закрытия полос или ДТП.
В этом примере задержка определяет, как быстро машина может добраться от
одного города до другого, а пропускная способность — сколько машин сможет
добраться до цели. Использовать полную емкость может быть трудно из-за
ошибок и пробок.
Пропускная способность сети измеряется объемом данных, передаваемым по
сети в битах в секунду (бит/с). Емкость сети определяется максимальным объ-
емом данных, которые могут быть обработаны в сетевом пайплайне. На рис. 6.2
изображена схема передачи данных между клиентом и сервером.
Рис. 6.2. Передача данных в сети
Кроме сети, концепция пропускной способности применима на уровне дисковых
накопителей. Пропускная способность диска — критическая метрика, описыва-
ющая, насколько быстро данные читаются с устройства хранения или записы-
ваются на него. Она измеряется в мегабайтах в секунду (Мбайт/с) и зависит от
двух основных факторов: количества операций ввода/вывода в секунду (IOPS)
и размера каждой операции ввода/вывода (средний размер ввода/вывода).
Пропускная
способность
(Мбайт/с)
Средний размер операции ввода/вывода (байты) х IOPS
10242
Компоненты этой формулы:
• средний размер операции ввода/вывода — средний размер каждой операции
чтения или записи в байтах. Изменяется в зависимости от рабочей нагрузки;
например, операции с базами данных могут иметь меньший размер операций
ввода/вывода по сравнению с потоковой передачей больших видеофайлов;
244 Глава 6. Факторы производительности
• IOPS (количество операций ввода/вывода в секунду) определяет, сколько
операций чтения или записи может обработать накопитель за секунду. Вы-
сокое значение IOPS характерно для быстрых систем хранения, способных
параллельно обрабатывать множество операций;
• пропускная способность (Мбайт/с) оценивает фактическую скорость
передачи данных накопителя. Она объединяет I OPS со средним размером
операции ввода/вывода для представления объема данных, который может
быть перемещен в систему хранения или из нее за секунду.
Чтобы преобразовать результат в Мбайт/с, мы делим произведение среднего
размера операции ввода/вывода и IOPS на 1024*1024 (1024 байт в килобайте,
1024 килобайта в мегабайте).
При IOPS дискового устройства = 20 000 и размере операции ввода/вывода =
4 Кбайт (4 * 1024 байта = 4096 байт) пропускная способность вычисляется, как
описано ниже.
1. Сначала размер ввода/вывода преобразуется из байтов в мегабайты:
размер операции ввода/вывода в Мбайт = 24^1024= 0-00390625 Мбайт.
2. Затем результат умножается на IOPS для получения пропускной способ-
ности в Мбайт/с:
пропускная способность = размер операции ввода/вывода в Мбайт х IOPS;
пропускная способность = 0,00390625 Мбайт х 20 000;
пропускная способность = 78,125 Мбайт.
Таким образом, при IOPS дискового устройства = 20 000 и размере операции
ввода/вывода = 4 Кбайт пропускная способность составит приблизительно
78,125 Мбайт/с.
В результате этих вычислений мы получаем общий объем данных, которые могут
быть прочитаны или записаны на диск за секунду при этих условиях.
На уровне операционной системы пропускная способность определяется объе-
мом данных, передаваемых между процессором и оперативной памятью за секун-
ду. На уровне базы данных пропускная способность определяется количеством
транзакций, которые могут быть обработаны базой данных за секунду. На уровне
приложения код должен обрабатывать транзакции, которые могут выполняется
каждую секунду, управляя памятью приложения с помощью системы сборки
мусора и эффективного использования кэша в памяти.
Когда речь заходит о задержке, пропускной способности и емкости, также
необходимо учитывать фактор конкурентности, который действует на раз-
ные компоненты архитектуры и помогает повысить производительность
приложения. В следующем разделе тема конкурентности рассматривается
более подробно.
Принципы проектирования высокопроизводительных архитектур 245
Конкурентность
Конкурентность (concurrency) играет важную роль в проектировании мас-
штабируемых и эффективных приложений. Механизм конкурентности по-
зволяет приложению выполнять несколько задач одновременно, чтобы более
эффективно использовать системные ресурсы и повышать общую произво-
дительность. Реализуя конкурентность в приложениях, разработчики могут
обеспечить выполнение нескольких операций одновременно, не ожидая завер-
шения одной задачи до запуска следующей. Конкурентность особенно важна
в веб-приложениях, которые обслуживают тысячи пользователей, и в задачах
обработки больших объемов данных. Реализация конкурентности может при-
вести к значительным улучшениям времени отклика и пропускной способности,
улучшению взаимодействия с пользователями и способности приложения
к масштабированию.
Параллелизм (parallelism) — еще одна важнейшая концепция проектирования
ПО, дополняющая конкурентность за счет одновременного выполнения не-
скольких операций на разных процессорах или ядрах. Если конкурентность
подразумевает выполнение сразу нескольких задач (например, многозадачность
на одноядерном процессоре, где задачи быстро переключаются для создания
иллюзии одновременного выполнения), параллелизм — это следующий шаг,
когда сразу несколько операций действительно выполняется на многоядерных
процессорах или в распределенных системах. Этот подход значительно ускоря-
ет обработку вычислительных
задач: работа разбивается на мень-
шие блоки, которые могут обраба-
тываться параллельно. Паралле-
лизм приносит огромную пользу
в приложениях, имеющих дело
с большими датасетами, произво-
дящих сложные вычисления, или
задачах, которые могут быть раз-
делены на независимые единицы.
Его применение обеспечивает по-
вышение пропускной способности
и эффективности.
Как показано на рис. 6.3, конку-
рентность можно сравнить со све-
тофором, управляющим потоком
движения на всех четырех поло-
сах. Когда на одной полосе идет
выполнение, движение на осталь-
ных полосах вынуждено остано-
виться. В случае параллелизма
Параллелизм
Рис. 6.3. Конкурентность и параллелизм
246 Глава 6. Факторы производительности
полосы не зависят друг от друга, и все машины могут двигаться параллельно,
не прерывая движение на других полосах, как показано на рис. 6.3.
База данных всегда является центральной точкой архитектуры. Конкурентность
играет важнейшую роль в работе с данными, так как база данных должна быть
способна реагировать на множество запросов одновременно. Конкурентная
работа с базами данных усложняется тем, что один пользователь может читать
запись в то время, когда другой пользователь будет пытаться обновить ее. База
данных должна допускать просмотр данных только после их полного сохране-
ния. Следите, чтобы данные были полностью сохранены, прежде чем другой
пользователь попытается обновить их.
Кэширование может заметно повысить производительность. Рассмотрим не-
которые типы кэшей, встречающиеся в архитектурах.
Кэширование
В главе 4 «Паттерны проектирования архитектур решений» вы научились
применять кэширование на разных уровнях архитектуры (раздел «Построение
архитектуры на базе кэша»). Кэширование помогает заметно улучшить произво-
дительность приложения. Хотя вы уже узнали о паттернах проектирования для
кэширования с использованием внешних механизмов (например, CDN), важно
понимать, что почти каждый компонент приложения и элемент инфраструк-
туры имеют собственный механизм кэширования. Применение кэширования
на каждом уровне помогает сократить задержку и повысить общую произво-
дительность приложения.
У центрального процессора (CPU) существует аппаратный кэш, который сокра-
щает задержку при обращении к данным из основной памяти. Кэш процессора
включает кэш команд и кэш данных; в кэше данных хранятся копии часто ис-
пользуемых данных. На уровне диска также применяется кэш, находящийся под
управлением операционной системы (так называемый страничный кэш); однако
все управление кэшем процессора полностью осуществляется на аппаратном
уровне. Кэш диска находится под управлением вторичной системы хранения,
такой как HDD ИЛИ SSD (Solid-State Disk). Часто используемые данные хра-
нятся в неиспользуемой части основной памяти (то есть в страничном кэше),
что ускоряет доступ к ним.
Часто у баз данных имеется механизм кэширования, который сохраняет ре-
зультаты, полученные из базы, для ускорения последующих обращений к ним.
Существует внутренний кэш, который содержит данные, определенные на основе
шаблонов обращений к базе данных. Также имеется кэш запросов, который
хранит данные в основной памяти сервера (RAM), если запрос был выполнен
более одного раза. Кэш запросов очищается в случае изменения данных в таб-
лице. Если на сервере возникнет нехватка памяти, результаты самого старого
запроса будут удалены, чтобы освободить место.
Выбор технологии для оптимизации производительности 247
На сетевом уровне имеется кэш DNS, который локально хранит на сервере до-
менные имена и соответствующие IP-адреса. Если позднее вы посетите тот же
сайт, кэширование позволит ускорить преобразование имен DNS. Операционная
система управляет кэшем DNS и содержит историю всех последних посещений
веб-сайтов. Вы узнали о механизмах кэширования на стороне клиента (таких,
как кэши браузера) и инструментах кэширования (Memcached и Redis) в главе 4
«Паттерны проектирования архитектур решений».
В этом разделе, посвященном принципам проектирования высокопроизво-
дительных архитектур, вы узнали об основных факторах проектирования (за-
держка, пропускная способность, кэширование), которые следует учитывать
для оптимизации производительности. С каждым компонентом архитектуры
(будь то сеть на уровне сервера или приложение на уровне базы данных) свя-
зан определенный уровень задержки и проблемы конкурентности, которые
необходимо решить.
Всегда проектируйте приложение с расчетом на желаемую производительность,
потому что ее повышение не дается даром. Конкретные способы оптимизации
производительности могут отличаться в зависимости от приложения. Архи-
тектура решения должна направлять усилия проектировщика — например,
приложение биржевой торговли не допускает даже миллисекундной задержки.
С другой стороны, для сайта интернет-магазина не критична задержка в не-
сколько секунд.
Перейдем теперь к выбору технологии для разных уровней архитектуры.
Выбор технологии для оптимизации
производительности
В главах 4 и 5 вы познакомились с различными паттернами проектирования,
включая микросервисные архитектуры, архитектуры, управляемые событиями,
архитектуры на базе кэшей и архитектуры без сохранения состояния. Организа-
ция может выбрать комбинацию этих паттернов в зависимости от потребностей.
Вы можете применить сразу несколько разных подходов к проектированию
архитектуры в зависимости от рабочей нагрузки. А когда вы определитесь со
стратегией и начнете реализовывать собственное решение, следующим шагом
станет оптимизация приложения. Чтобы оптимизировать приложение, необхо-
димо собрать информацию касательно требований к его производительности
с помощью нагрузочного тестирования и бенчмаркинга.
Оптимизация производительности — процесс непрерывного совершенствования,
в котором необходимо учитывать оптимальное использование ресурсов от самого
начала проектирования до запуска приложения. Вы должны правильно выбрать
ресурсы в соответствии с рабочей нагрузкой или настроить конфигурацию при-
ложения и инфраструктуры. Например, можно выбрать базу данных NoSQL для
хранения состояния сессии и хранить транзакции в реляционной базе данных.
248 Глава 6. Факторы производительности
Для аналитики и построения отчетов можно разгрузить рабочую базу данных —
выгрузите информацию в отдельное решение для хранения и создавайте отчеты
из него.
В случае серверов можно использовать виртуальную машину или контейнеры.
Можно выбрать полностью бессерверную схему для построения и развертывания
кода приложения. Независимо от технологии и рабочей нагрузки приложения
необходимо выбрать основной тип ресурса: вычисления, хранение, база данных
или сеть. Рассмотрим выбор типа ресурса для оптимизации производительности
более подробно.
Выбор вычислительного ресурса
В этом разделе мы будем использовать термин «вычислительный ресурс» вме-
сто «сервер», так как развертывание продукта в наши дни не ограничивается
серверами. У провайдеров публичных облачных платформ (таких, как AWS)
имеются бессерверные предложения, где для выполнения приложения не нужен
сервер. Одно из самых популярных предложений FaaS (функция как сервис) —
AWS Lambda. У других популярных провайдеров облачных платформ тоже
есть решения в стиле FaaS — например, Azure Functions у Microsoft Azure или
Google Cloud Functions у GCP.
Впрочем, организации обычно выбирают стандартный вариант: серверы с вир-
туальными машинами. Контейнеры также приобретают популярность, так
как потребность в автоматизации и использовании ресурсов возросла. Сейчас
контейнерам отдают предпочтение, особенно в области развертывания микро-
сервисных приложений.
Оптимальный выбор вычислительного ресурса — независимо от того, выбрали
ли вы экземпляры серверов, контейнеры или бессерверные схемы, — зависит
от сценария использования приложения. Рассмотрим различные варианты вы-
числительных ресурсов.
В таблице 6.1 приведена сводка различий между процессорами (CPU),
графическими процессорами (GPU), программируемыми пользователем
вентильными матрицами (FPGA) и специализированными интегральными
схемами (ASIC) с акцентом на их основные области применения, простоту
программирования, архитектуру ядер, стоимость и пригодность для парал-
лельных вычислений, а также другие характеристики. Для начала определимся
с терминами.
• Центральный процессор (CPU, Central Processing Unit) — центральный
процессор компьютера, выполняющий большую часть операций обработки
данных; часто сравнивается с «мозгом» компьютера.
• Графический процессор (GPU, Graphic Processing Unit) — специализиро-
ванная микросхема, предназначенная для быстрого выполнения операций
Выбор технологии для оптимизации производительности 249
и модификации памяти, чтобы ускорить создание изображений в буфере
кадра, предназначенном для вывода на экран.
• Программируемая пользователем вентильная матрица (FPGA, Field
Programmable Gate Array) — интегральная схема, которая должна настра-
иваться клиентом или проектировщиком после производства — отсюда
«программируемая».
• Специализированная интегральная схема (ASIC, Application-Specific
Integrated Circuit) — микросхема, специализированная для целевого (не
универсального) применения.
Можно использовать один или несколько вариантов этих процессоров в зави-
симости от рабочей нагрузки.
Таблица 6.1. Сравнение разных типов вычислительных ресурсов
Особенность CPU GPU FPGA ASIC
Основное применение Приложе- ния обще- го назна- чения Работа с графи- кой, обработка больших дан- ных Программируе- мое устройство для специа- лизированных задач Специализиро- ванные целевые интегральные схемы
Простота программи- рования Просто Требует знания специализиро- ванных библи- отек (например, CUBA) Сложное, тре- бует навыков аппаратного программиро- вания - (устройство проектируется для единственной цели)
Многозадач- ность Да Ограничивается поддержкой параллелизма при проектиро- вании Да — при изме- нении конфигу- рации Нет — узкоспе- циализированное устройство
Универсаль- ность Высокая Умеренная Умеренная, возможно изме- нение конфигу- рации для кон- кретных задач Низкая, привязка к применению
Метрика про- изводитель- ности ГГц (мил- лиарды тактов в секунду) TFLOP (триллионы операций с пла- вающей точкой в секунду) Может изме- ряться в FLOP (операциях с плавающей точкой в секун- ду) Оптимизируется для снижения энергопотребле- ния и увеличения производитель- ности
Структура ядра Несколько больших ядер Тысячи неболь- ших ядер Логические эле- менты, которые можно пере- настраивать Нет — узкоспе- циализированное устройство
250 Глава 6. Факторы производительности
Продолжение
Особенность CPU GPU FPGA ASIC
Параллель- ная обра- ботка Ограни- чена Высокая, с массово-па- раллельной об- работкой (МРР, Massively Paral- lel Processing) Поддерживает МРР, настраи- вается как CPU Оптимизируется для конкретных применений
Затраты Низкие Выше, чем у CPU Выше, чем у CPU и GPU, требует на- стройки Самые высокие из-за нестандарт- ной архитектуры и долгого цикла разработки
Энергопотре- бление Умеренное Высокое Низкое Оптимизировано для применения
Г ибкость Универ- сальность в широком спектре примене- ний Специализиро- вана для при- менений с ин- тенсивными вычислениями Может перена- страиваться, но требует разра- ботки Фиксированное применение, требует перепро- ектирования для изменений
Цикл разра- ботки Короткий От короткого до умеренного Длинный из-за необходимости пользователь- ской настройки Самый длинный, требует перепро- ектирования на уровне оборудо- вания
В табл. 6.1 сравниваются разные типы вычислительных ресурсов. ASIC — самый
эффективный вариант, но требует длительного цикла разработки для реализации.
ASIC обеспечивает оптимальную производительность, но имеет наименьшую
гибкость для перепрофилирования, тогда как CPU чрезвычайно гибкие и под-
ходят для многих сценариев использования.
В наши дни CPU получили широкое распространение и применяются по-
всеместно для устройств общего назначения в целях снижения затрат. GPU
весьма популярны в приложениях с интенсивными вычислениями, a FPGA
становятся предпочтительными в узкоспециализированных ситуациях. Эти
варианты доступны от провайдеров публичных облачных платформ, таких
как AWS.
В этом разделе были рассмотрены самые популярные варианты вычислительных
ресурсов. Вероятно, вы слышали и о других типах процессоров — например,
ускоренных процессорах (APU, Accelerated Processing Unit). APU объединяет
CPU, GPU и цифровой сигнальный процессор (DSP, Digital Signal Processor),
что оптимально для анализа аналоговых сигналов и требует скоростной обра-
ботки данных в реальном времени.
Выбор технологии для оптимизации производительности 251
В следующем разделе рассматриваются контейнеры, которые быстро набирают
популярность благодаря способности оптимизировать использование ресурсов
в виртуальной машине.
Работа с контейнерами
В главе 4 «Паттерны проектирования архитектур решений» вы узнали о пре-
имуществах контейнерного развертывания (раздел «Развертывание приложения
в контейнере»). Применение контейнеров становится нормой при развертыва-
нии сложных микросервисных приложений благодаря простоте автоматизации
и эффективности использования ресурсов. Существует целый ряд платформ
для развертывания контейнеров.
Благодаря своей популярности и платформенно-независимой функционально-
сти контейнеры стали основным средством построения облачно-независимых
платформ. Контейнеры можно развертывать в собственном локальном центре
данных и управлять ими из облака. Также можно выбрать вариант с релокацией
и переместить контейнер из локальной среды в облако, не внося изменений
в приложение.
С контейнером можно построить мультиоблачную платформу, а в наши дни все
крупные провайдеры публичных облачных платформ предоставляют инструмен-
ты для управления контейнерной средой, охватывающей несколько платформ.
Например, AWS предоставляет сервис ECS Anywhere, позволяющий запускать
контейнерные рабочие нагрузки и легко управлять ими в инфраструктуре, на-
ходящейся под управлением клиента. Аналогичным образом GCP предоставляет
сервис Google Anthos, также обеспечивающий управление контейнерами между
локальными и другими облачными платформами.
Обсудим некоторые популярные варианты контейнеров и посмотрим, чем они
различаются и как работают совместно.
Docker
Docker — одна из наиболее востребованных технологий. Docker позволяет
упаковать приложение и его зависимости в контейнере и развернуть в любой
операционной системе. Docker предоставляет приложениям платформенно-
независимую функциональность, что упрощает и делает более доступными
разработку приложения в целом, а также процессы тестирования и развер-
тывания.
Контейнеры Docker помогают строить сложные многоуровневые приложе-
ния. Представим, что вам нужно запустить сервер приложения, базу данных
и очередь сообщений одновременно. В таком случае можно запустить их
параллельно из разных образов Docker и установить связи между ними.
На каждом из этих уровней могут существовать свои измененные версии
библиотек, a Docker позволяет им работать на одном вычислительном ресурсе
без конфликтов.
252 Глава 6. Факторы производительности
Образы контейнеров Docker могут портироваться между системами по локальной
сети или по интернету с использованием Docker Hub. Для управления контейне-
рами и их распространения можно воспользоваться репозиторием контейнеров
Docker Hub. Допустим, вы внесли в образ Docker изменения, которые вызвали
проблемы в среде. В этом случае можно легко вернуться к работоспособной
версии образа, что заметно упрощает устранение неполадок.
При использовании Docker команда разработки строит приложение и упако-
вывает его с необходимыми зависимостями в образ. Этот образ выполняется
в контейнере на хосте Docker. По аналогии с управлением кодом в репозиториях
(например, Git Hub) образы Docker также должны храниться в реестре. Docker
Hub — общедоступный реестр, а другие провайдеры публичных облачных
платформ предоставляют собственные реестры — например, AWS ECR (Elastic
Container Registry) и Azure Container Registry. Кроме того, можно создать свой
локальный приватный реестр для образов Docker.
Провайдеры публичных облачных платформ (таких, как AWS) предоставляют
платформы управления контейнерами — например, Amazon ECS. Эти средства
позволяют управлять контейнерами Docker поверх облачной виртуальной маши-
ны, Amazon ЕС2. AWS также предлагает бессерверный вариант развертывания
контейнеров на базе Amazon Fargate, позволяющий развертывать контейнеры
без виртуальной машины.
Сложные корпоративные приложения строятся на базе микросервисов, которые
могут охватывать несколько контейнеров. Управлять разными контейнерами
Docker как частью приложения может быть непросто. Платформа Kubernetes
помогает решать проблемы мультиконтейнерных сред.
Познакомимся с Kubernetes поближе.
Kubernetes
Kubernetes превосходно проявляет себя в управлении и координации нескольких
контейнеров в рабочей среде, действуя как всесторонняя система оркестрации
контейнеров. Kubernetes поддерживает размещение контейнеров Docker на фи-
зических серверах или узлах виртуальных машин, которые обычно называются
рабочими узлами. Kubernetes эффективно координирует операции в кластерах
таких узлов, автоматизируя развертывание, масштабирование и управление
контейнеризованными приложениями, что гарантирует плавную и надежную
работу приложения в инфраструктуре.
Kubernetes обеспечивает самовосстановление приложений, так как контей-
неры, не отвечающие из-за ошибки приложения, автоматически заменяются.
Kubernetes также предоставляет возможности горизонтального масштабирова-
ния и сине-зеленого развертывания для предотвращения простоев. Kubernetes
распределяет нагрузку пользовательского трафика между контейнерами
и управляет пространством хранения, совместно используемым разными
контейнерами.
Выбор технологии для оптимизации производительности 253
На рис. 6.4 показано, как Kubernetes и Docker совместно работают над орке-
страцией приложения. Kubernetes обеспечивает сетевые коммуникации между
рабочими узлами и контейнерами Docker.
Docker Ядро Kubernetes
Кластер Kubernetes
Рис. 6.4. Docker и Kubernetes
Docker работает как отдельная часть приложения, a Kubernetes обеспечивает
оркестрацию для гарантии того, что все части приложения работают, как было
задумано проектировщиком. Kubernetes позволяет легко автоматизировать раз-
вертывание и масштабирование всего приложения. В Docker контейнеры раз-
мещаются в узлах, и все контейнеры Docker в одном узле совместно используют
одно пространство IP-адресов. В Docker необходимо управлять связями между
контейнерами, разрешая любые конфликты IP. Kubernetes решает эту проблему
созданием основного (primary) экземпляра, в котором отслеживаются все узлы
с размещенными подами.
Основной узел Kubernetes назначает IP-адрес, поддерживает хранилище пар
«ключ — значение» для конфигурации контейнера, а также запускает агент
kubelet для управления контейнерами. Kubelet — основной «узловой агент»,
который выполняется на каждом узле и следит за тем, чтобы контейнеры,
определенные в подах, были запущены и продолжали работать. Контейнеры
254 Глава 6. Факторы производительности
Docker группируются в поды (pods), использующие один IP-адрес. Вся группа
называется кластером Kubernetes.
Система Kubernetes сложна в обслуживании. Облачные провайдеры предостав-
ляют для нее собственные средства управления. Например, AWS предоставляет
сервис Amazon EKS (Elastic Kubernetes Service) для упрощения управления
кластером Kubernetes. OpenShift — еще один дистрибутив Kubernetes под
управлением Red Hat — представляется в форме «платформа как сервис» (PaaS,
Platform as a Service). В свою очередь, Microsoft Azure предоставляет сервис AKS
(Azure Kubernetes Service), a GCP — сервис GKE (Google Kubernetes Engine),
предлагающие простые средства для развертывания, масштабирования и авто-
матического управления Kubernetes.
В целом контейнеры добавляют уровень виртуализации во всю инфраструктуру
приложения. Они полезны для эффективного использования ресурсов, но если
приложение требует сверхнизкой задержки, выбирайте физическую машину
для его развертывания.
Бессерверные решения
Бессерверные вычисления стали возможны благодаря популярности решений
от провайдеров публичных облачных платформ — таких, как Amazon, Google
и Microsoft. Бессерверные вычисления позволяют разработчикам сосредото-
читься на коде и разработке приложения, не беспокоясь о нижележащей инфра-
структуре масштабирования, выделения ресурсов и настройки. Бессерверные
решения абстрагируют управление серверами и инфраструктурой, отделяют эти
процессы от разработчика и позволяют ему сосредоточиться на своей области
компетенции и бизнес-задачах, которые он решает. Бессерверные вычисления
приводят нас к относительно новой концепции «функция как сервис» (FaaS,
Function as a Service).
Предложения FaaS доступны от AWS Fambda, Microsoft Azure Functions и Google
Cloud Functions. Например, можно написать код в облачном редакторе, a AWS
Fambda возьмет на себя управление нижележащей вычислительной инфраструк-
турой для выполнения и масштабирования написанных функций. Можно спро-
ектировать архитектуру, управляемую событиями, или RESTful-микросервисы,
добавив конечную точку API при помощи Amazon API Gateway и функций AWS
Fambda. Amazon API Gateway — обслуживаемая облачная система, которая
добавляет RESTful-API и WebSocket API в качестве фронтендов для функций
Fambda и делает возможными коммуникации между приложениями в реальном
времени. Можно продолжить разбиение микросервисов на меньшие задачи,
которые могут масштабироваться автоматически и независимо.
Помимо возможности сосредоточиться на коде, с моделью FaaS вам никогда
не придется платить за простаивающие ресурсы. Вы можете независимо мас-
штабировать только необходимые функции, а не весь сервис, со встроенными
средствами доступности и отказоустойчивости. Однако при необходимости
Выбор технологии для оптимизации производительности 255
оркестрировать тысячи компонентов предсказать затраты на автомасштабирова-
ние может быть непросто. Такое решение идеально подходит для планирования
заданий, обработки веб-запросов и ведения очередей сообщений.
В этом разделе вы узнали о том, какие вычислительные ресурсы могут использо-
ваться для оптимизации производительности. Мы рассмотрели экземпляры сер-
веров, контейнеры и бессерверные решения. Выбирайте сервисы в соответствии
с требованиями своего приложения. Не существует правил, предопределяющих
выбор конкретного способа вычислений; все зависит от технологического стека
организации, темпа инноваций и природы приложения.
Как бы то ни было, для монолитных приложений обычно можно без особого
риска выбрать виртуальную или физическую машину, а для сложных микро-
сервисов — контейнеры. Для планирования простых задач или приложений,
управляемых событиями, бессерверные функции — очевидный вариант. Многие
организации строят сложные приложения полностью на бессерверных вычис-
лениях, что помогает им сократить затраты и добиться высокой доступности
без необходимости управлять инфраструктурой.
Рассмотрим другой важный вопрос инфраструктуры и то, как его решение может
помочь в оптимизации производительности.
Выбор типа хранилища
Хранение данных играет ключевую роль в производительности любого прило-
жения, и концепция локальности данных (data affinity) чрезвычайно важна при
обсуждении организации хранения в приложении. Под локальностью данных
понимается стратегическое размещение данных рядом с приложением, которое
эти данные потребляет, с целью сокращения задержки, повышения произво-
дительности и обеспечения эффективного чтения данных.
В мультиоблачных или гибридных облачных средах представление о том, что все
данные должны храниться в непосредственной близости от сервера приложения,
не всегда истинно. Современные распределенные системы проектируются так,
чтобы данные могли храниться в разных местах — как локально, так и у других
облачных провайдеров, при этом сохраняя приемлемые уровни задержки и про-
изводительности. Такая гибкость критична для организаций, использующих
разные облачные сервисы, или для организаций, у которых, согласно требова-
ниям к хранению, некоторые данные должны оставаться в определенных гео-
графических или законодательных границах.
Тем не менее при принятии решений о том, где должны храниться данные —
рядом с сервисом приложения или в другом месте, — необходимо тщательно
взвесить ряд факторов.
• Требования к задержке: допустимая задержка между запросом и ответом
может значительно повлиять на выбор места хранения. Приложения, кото-
рым необходима доступность данных в реальном времени, могут требовать
256 Глава 6. Факторы производительности
способов хранения с минимальной задержкой, что часто подразумевает
близкое размещение (физическое или сетевое).
• Суверенитет данных и комплаенс: юридические и нормативные требова-
ния могут предписывать, где должны храниться и обрабатываться данные.
Архитектура должна соответствовать этим требованиям.
• Затраты: хранение и работа с данными, расположенными в разных местах
или облачных платформах, могут приводить к дополнительным затратам.
Очень важно сочетать требования к производительности с ограничениями
бюджета, особенно с учетом платы за исходящие данные в облачных средах.
• Емкость и пропускная способность: емкость и пропускная способность
сети между сервером приложения и местом хранения данных могут влиять
на производительность. Высокая емкость и пропускная способность могут
решить некоторые проблемы с задержкой, делая доступными более гибкие
варианты хранения данных.
• Шаблоны обращения к данным: если вы имеете представление о том, как
ваше приложение обращается к данным (например, к каким данным оно
обращается часто, а к каким редко), это поможет вам выбрать подходящее
хранилище. Если данные, к которым приложение обращается часто, хранятся
рядом с ним, это может ускорить доступ.
• Аварийное восстановление и доступность: стратегии устойчивости данных
могут требовать, чтобы данные реплицировались в разных местах для обес-
печения доступности в случае сбоев.
В мультиоблачных стратегиях кэширование, репликация данных или перифе-
рийные вычисления могут помочь с соблюдением стандартов производитель-
ности за счет хранения синхронизированной копии критических данных рядом
с приложением независимо от места хранения основных данных. Такие приемы
позволяют приложениям обращаться к данным с минимальной задержкой, даже
если первоисточник данных находится на значительном удалении.
Выбор способа хранения зависит от тщательного анализа перечисленных фак-
торов. Старайтесь выдержать баланс между эксплуатационными требованиями,
производительностью, затратами и обеспечением комплаенса. Ваша конечная
цель — создать решение, удовлетворяющее требованиям к производительности
и при этом соблюдающее организационные, юридические и бюджетные огра-
ничения.
Сначала необходимо решить, должны ли данные содержаться в блоковом,
файловом или объектном хранилище. В этих форматах данные хранятся и пред-
ставляются по-разному. Рассмотрим их более подробно.
Блоковые хранилища и сети хранения данных
Блоковое хранилище делит данные на блоки и хранит их как фрагменты данных.
Каждый блок обладает уникальным идентификатором, что позволяет системе
размещать данные там, где они будут наиболее легкодоступны, так как в блоках
Выбор технологии для оптимизации производительности 257
не хранятся никакие метаданные о файлах. Серверная операционная система
управляет этими блоками на жестком диске и использует их. Каждый раз, когда
система запрашивает данные, система хранения собирает нужные блоки и воз-
вращает результат пользователю.
Блоковое хранилище, развернутое в сети хранения данных (SAN, storage area
network), эффективно в тех случаях, когда требуется хранить большой объем дан-
ных, к которым необходимо часто обращаться — например, при развертывании
базы данных, серверов электронной почты, приложения и виртуальных машин.
В S AN используется комплексная система хранения, способная обеспечить работу
сложных, критически важных приложений. Это высокопроизводительная система
хранения, передающая блоковые данные между сервером и хранилищем; с другой
стороны, решения SAN обходятся дорого, и применять их следует только для
крупномасштабных корпоративных приложений, требующих низкой задержки.
Чтобы настроить блоковое хранилище, необходимо выбрать между SSD и HDD.
HDD (жесткие диски) — устаревшая система хранения данных для серверов
и корпоративных массивов хранения данных. HDD стоят недорого, но рабо-
тают медленно, а также требуют питания и охлаждения. SSD (твердотельные
накопители) используют полупроводниковые микросхемы и работают быстрее
HDD. Они стоят заметно дороже, однако с развитием технологии устройства
SSD стали более доступными и популярными благодаря своей эффективности
и более низким требованиям к питанию и охлаждению.
Файловые и сетевые хранилища данных
Файловые хранилища существуют уже давно и широко применяются на прак-
тике. В них данные хранятся в виде одной информационной единицы и имеют
иерархическую структуру. Когда вам требуется обратиться к данным, вы ука-
зываете путь и получаете файлы данных. Впрочем, пути могут быть достаточно
сложными, если файлы образуют многоуровневые иерархии.
Каждая запись содержит ограниченный объем метаданных, включая имя файла,
время создания и обновленные метки времени. Можно сравнить такое храни-
лище с библиотекой, в которой книги стоят на полках, а в картотеке хранятся
карточки с информацией о местонахождении каждой книги.
Сетевое хранилище данных, или NAS (Network area storage) — система хранения
файлов, подключенная к сети. В ней пользователь может хранить свои файлы
и работать с ними. NAS также управляет привилегиями доступа, блокированием
файлов и другими механизмами безопасности. Технология NAS хорошо подходит
для файлообменных систем и локальных архивов. Но для хранения большого
количества файлов существуют и более совершенные решения, так как NAS
хранит ограниченную информацию метаданных и использует сложную иерархию
каталогов. Для хранения миллиардов файлов лучше использовать объектные
хранилища. В следующем разделе объектные хранилища и их преимущества
по сравнению с файловыми хранилищами рассматриваются более подробно.
258 Глава 6. Факторы производительности
Объектные и облачные хранилища данных
В объектном хранилище данные дополняются уникальным идентификатором
и метаданными, которые могут настраиваться. Объектное хранилище использует
плоское адресное пространство — в отличие от иерархических адресов в фай-
ловом хранилище или адресов, распределенных по группе блоков в блоковых
хранилищах. Плоское адресное пространство упрощает поиск и быстрое полу-
чение данных независимо от их местоположения. Объектное хранилище также
помогает пользователю достичь неограниченной масштабируемости хранимых
данных.
Метаданные в объектных хранилищах могут содержать многочисленные по-
дробности: имя объекта, размер, метку времени и т. д., причем пользователи
могут настраивать эти метаданные для дополнительной информации, которая
в файловых хранилищах определяется при помощи тегов. Обращение к данным
производится простым вызовом API, и такая организация хранения чрезвычайно
эффективна экономически. Объектные хранилища лучше всего подходят для
больших объемов неструктурированных данных; с другой стороны, объекты нель-
зя изменять — только заменять, и база данных для такого сценария не подойдет.
Облачные хранилища данных — такие, как Amazon S3 (Simple Storage Service) —
предоставляют неограниченное масштабируемое пространство для хранения
объектов, обладающее высокой доступностью и долговечностью. К данным
можно обращаться по уникальному глобальному идентификатору и префиксу
файла метаданных.
На рис. 6.5 представлены все три системы хранения.
Объектное
хранилище
Файловое хранилище
Рис. 6.5. Системы хранения данных
Как показано на диаграмме, в блоковом хранилище данные хранятся по блокам.
Блоковое хранилище идеально подходит для сценариев, когда одному экземпляру
необходим монопольный доступ к хранилищу — например, базам данных или
приложениям, требующим высокой производительности и быстрых обращений
Выбор технологии для оптимизации производительности 259
к данным. В файловом хранилище данные хранятся в виде иерархической струк-
туры каталогов, создающей небольшую дополнительную задержку. Используйте
файловую систему хранения, если к данным должны одновременно обращаться
сразу несколько экземпляров. В объектных хранилищах данные хранятся в ба-
кетах, при этом каждому объекту присваивается уникальный идентификатор.
Объектные хранилища предоставляют доступ к данным по сети для сокраще-
ния задержки и повышения пропускной способности. Используйте объектные
хранилища для хранения статического контента (например, графики и видео).
В объектных хранилищах можно хранить большие объемы данных, выполнять
обработку и анализ больших данных.
Система хранения с прямым подключением, или DAS (Direct-Attached
Storage), — еще одна разновидность хранилищ данных, напрямую подключаемая
к серверу-хосту. Однако DAS обладает очень ограниченной масштабируемостью
и емкостью хранения.
Магнитные ленты — еще одна популярная система хранения для резервного
копирования и архивации. Благодаря своей низкой стоимости и высокой до-
ступности накопители на магнитных лентах применяются для хранения ар-
хивных данных, но из-за высокой задержки они плохо подходят для прямого
использования в приложениях.
Часто требуется повысить пропускную способность и защиту данных для
критически важного приложения (например, транзакционной базы данных),
хранящего данные в хранилище SAN.
Чтобы добиться максимальной производительности, выбирайте способ хранения,
соответствующий шаблонам обращения к данным. Для блокового, файлового
и объектного метода хранения существуют различные облачные варианты. На-
пример, публичная облачная платформа AWS предлагает Amazon EBS (Elastic
Block Store) в качестве SAN-хранилища в облаке и Amazon EFS (Elastic File
System) в качестве облачного хранилища NAS.
Среди объектных хранилищ чрезвычайно популярен сервис Amazon S3. Анало-
гичным образом Microsoft Azure предлагает Azure Disk Storage в качестве SAN,
Azure Files в качестве NAS и Azure Blob Storage в качестве блокового хранилища.
Механизмы хранения для баз данных
Правильный выбор технологии хранения БД играет ключевую роль для обес-
печения оптимальной эксплуатации и эффективности. Выбор часто зависит от
конкретных требований рабочей нагрузки базы данных (например, IOPS, размера
БД, географического местоположения используемых данных и природы опера-
ций с БД — OLTP (Online Transaction Processing) или OLAP (Online Analytical
Processing)). В табл. 6.2 сравниваются критерии выбора и применимость разных
технологий хранения для баз данных.
260 Глава 6. Факторы производительности
Таблица 6.2. Сравнение разных типов хранения
Технология хранения Значение IOPS Размер БД Выбор места Лучший сценарий использо- вания Для чего подходит
SSD Высокое От малого до боль- шого Вблизи от сервера приложе- ния OLTP и OLAP Хорошо подходит для большинства БД, особенно когда критичны высокое значение IOPS и низкая задержка
HDD От уме- ренного до высо- кого Большой Рядом с серве- ром при- ложения Большие системы OLAP Подходит для больших БД с нечастыми об- ращениями или с ограничениями по затратам, но не рекомендуется для высокопроизво- дительных систем OLTP
NAS От низ- кого до умерен- ного От малого до сред- него Г ибкий, возможно нелокаль- ное разме- щение OLAP и ре- зервное копирова- ние Подходит для БД с умеренными требованиями к производитель- ности и для целей резервного копи- рован ия/архивиро- вания
SAN Высокий Большой Г ибкий, желатель- нопобли- зости OLTP и OLAP Хорошо подходит для больших БД, требующих высо- ких IOPS, пропуск- ной способности и масштабируемо- сти. Может разме- щаться локально или в облаке
Облачное хранилище Перемен- ное Перемен- ный Локально или в об- лаке OLTP и OLAP Подходит для ши- рокого диапазона размеров и типов БД. Производи- тельность и приме- нимость зависят от конкретных пред- ложений облачных сервисов
Выбор технологии для оптимизации производительности 261
В сценариях, включающих мультиоблачные и гибридные конфигурации, допол-
нительные факторы — такие, как суверенитет данных и соответствие стандартам
(которые определяют, где данные должны храниться согласно нормативным
требованиям), шаблоны обращений (интенсивное чтение или запись), сетевая
задержка, емкость сети и затраты — также приобретают большое значение. Эти
вопросы особенно важны при обращении к базам данных через глобальные сети
(Wide Area Network, WAN), в которых задержки могут повлиять на произво-
дительность.
После выбора подходящих вычислительных ресурсов и технологии хранения,
необходимой для достижения оптимальной производительности, рассмотрим
следующую важную составляющую разработки приложения: базу данных. Вы-
бор базы данных, подходящей под потребности, повысит производительность
приложения и сократит общую задержку. Существуют разные типы баз данных,
и при проектировании очень важно выбрать верный.
Выбор базы данных
Часто требуется стандартизировать общую платформу и использовать базу
данных для простоты управления; тем не менее старайтесь использовать разные
решения в зависимости от требований к данным. Неверный выбор базы данных
может отразиться на задержке и производительности системы.
Выбор БД зависит от требований к доступности, масштабируемости, структуре
данных, пропускной способности и стабильности приложения. При выборе
приходится учитывать множество факторов. Например, шаблоны доступа мо-
гут значительно повлиять на выбор технологии в зависимости от количества
пользователей и частоты обращений к данным. Желательно оптимизировать
свою базу данных на основе шаблонов доступа.
У баз данных обычно имеются параметры конфигурации для оптимизации
рабочей нагрузки. Рассмотрите возможности настройки конфигурации памяти,
кэша, оптимизации хранения и т. д. Также изучите особенности эксплуатации
технологий баз данных в отношении масштабируемости, резервного копиро-
вания, восстановления и обслуживания. Рассмотрим технологии БД, которые
могут использоваться для выполнения требований приложений к базам данных.
OLTP
В большинстве традиционных реляционных баз данных используется обработка
транзакций в реальном времени, или OLTP (Online Transactional Processing).
Транзакционные базы данных — самый старый и популярный метод хранения
и обработки данных приложений. К числу реляционных OLTP-баз данных от-
носятся Oracle, Microsoft SQL Server, MySQL, PostgreSQL и Amazon RDS. Схема
доступа к данным для OLTP подразумевает небольшую выборку данных по иден-
тификатору. Транзакция базы данных означает, что либо все задействованные
обновления базы данных успешно завершаются, либо не завершается ни одно.
262 Глава 6. Факторы производительности
Реляционная модель может обрабатывать в приложениях сложные бизнес-опера-
ции: банковские, торговые и т. д. Она позволяет агрегировать данные и создавать
сложные запросы с соединением нескольких таблиц.
В процессе оптимизации реляционной базы данных необходимо учитывать
следующее.
• Сервер базы данных и его отдельные параметры: вычислительная мощность,
память, хранилище и сеть.
• Настройки уровня операционной системы: тома для хранения, управление
томами и размер блока.
• Конфигурация и секционирование ядра базы данных.
• Средства, относящиеся к базе данных: схемы, индексы, представления.
Масштабирование реляционных баз данных затруднено, так как они масштаби-
руются вертикально и достигают верхнего предела мощности системы. Исполь-
зуйте реплики для чтения, чтобы распределить нагрузку. Это позволит сместить
запросы чтения с основной базы данных на одну или несколько реплик, улучшая
общую пропускную способность системы для чтения. Для масштабирования
записи реализуйте шардирование. Разбивая большой набор базы данных на
меньшие, более удобные части (сегменты, или шарды), каждая из которых имеет
свое подмножество данных, можно распределить нагрузку записи по нескольким
серверам или экземплярам, тем самым повышая эффективность записи.
В главе 4 вы узнали, как масштабировать реляционную базу данных (раздел
«Работа с базой данных в архитектуре приложения»).
Базы данных OLTP подходят для больших и сложных транзакционных при-
ложений; однако из-за необходимости агрегировать большие объемы данных
и обрабатывать запросы к ним возникает потребность в более эффективном
масштабировании. Кроме того, с развитием интернета отовсюду поступает
много неструктурированных данных, а реляционные БД в исходной форме не
могут эффективно работать с ними. На помощь приходят нереляционные базы
данных (NoSQL). Рассмотрим работу с ними более подробно.
Нереляционные базы данных
Приложения (социальные сети), 1оТ (интернет вещей), данные истории про-
смотров и журналы генерируют огромное количество неструктурированных или
полуструктурированных данных с чрезвычайно динамичными схемами. Эти
типы данных могут использовать разные схемы для каждого набора записей.
Хранение таких данных в реляционной БД может оказаться очень утомитель-
ной задачей. Все необходимо преобразовать к фиксированной схеме, что может
привести либо к появлению множества значений null, либо к потере данных.
Нереляционные базы данных, обычно обозначаемые сокращением NoSQL («Not
Only SQL», то есть «не только SQL»), предоставляют гибкий подход к хранению
и управлению данными. В отличие от традиционных реляционных БД, которые
Выбор технологии для оптимизации производительности 263
требуют создать фиксированную схему перед сохранением данных, базы данных
NoSQL позволяют хранить данные и управлять ими без предварительно опре-
деленных ограничений схемы. Записи с разным количеством столбцов могут
храниться в одной таблице.
Базы данных NoSQL способны хранить большие объемы данных и обеспечивают
низкую задержку. При необходимости они легко масштабируются добавлением
новых узлов и изначально поддерживают горизонтальное масштабирование.
Они отлично подходят для хранения данных пользовательских сессий и пере-
хода к приложению без сохранения состояния для реализации горизонтального
масштабирования без ущерба для пользовательских взаимодействий. Можно
разработать распределенное приложение поверх базы данных No SQL, которая
обеспечивает хорошую задержку и масштабирование, но соединение запросов
должно обрабатываться на уровне приложения, потому что базы данных No SQL
не поддерживают сложные запросы (например, соединения таблиц и сущностей).
Существует много разных баз данных No SQL (Cassandra, HBase, MongoDB
и т. д.), которые могут устанавливаться в кластере виртуальных машин. AWS
предоставляет управляемую базу данных No SQL, которая называется Amazon
DynamoDB и обеспечивает высокую пропускную способность с субмиллисе-
кундной задержкой и неограниченными возможностями масштабирования.
OLTP может использоваться с реляционными базами данных, но ограничивается
емкостью хранилища. Базы данных должны лучше реагировать на запросы боль-
ших объемов данных и проводить агрегирование в соответствии с потребностями
хранилищ. Эти потребности имеют более аналитическую, нежели транзакци-
онную природу. OLAP заполняет пробелы в возможностях OLTP, касающихся
запросов к большим наборам данных. Рассмотрим OLAP более подробно.
OLAP
OLTP и базы данных No SQL полезны для развертывания приложений, но их
возможности крупномасштабного анализа ограниченны. В хранилищах данных
в основном используется технология аналитической обработки данных в ре-
альном времени, или OLAP (Online Analytical Processing). Запрос большого
объема структурированных данных для аналитических целей лучше обслу-
живается платформой хранилища, спроектированной для ускорения доступа
к структурированным данным. Современные хранилища данных используют
форматы колоночного, или столбцового, хранения и массово-параллельную
архитектуру (МРР, massively parallel processing) для значительного ускорения
выборки данных и анализа. В отличие от традиционных строковых баз данных,
в которых данные хранятся по строкам, в колоночном хранилище данные струк-
турируются по столбцам (колонкам).
Колоночный формат означает, что не придется сканировать всю таблицу, если
нужно агрегировать только один столбец данных — например, если требуется
определить объем продаж за заданный месяц. Таблица заказов может содержать
264 Глава 6. Факторы производительности
сотни столбцов, но вам нужно агрегировать данные только по столбцу продаж.
С колоночным форматом достаточно сканировать один столбец, что сокращает
объем сканируемых данных по сравнению со строковым форматом и повышает
эффективность запроса.
С МРР данные хранятся в распределенном виде между дочерними узлами, и за-
прос отправляется ведущим узлам. На основании ключа сегментации ведущий
узел распределяет запросы между дочерними узлами. Каждый узел получает
часть запроса для выполнения параллельной обработки. Затем ведущий узел
собирает результаты подзапросов от всех дочерних узлов и возвращает агре-
гированный результат. Параллельная обработка помогает быстрее выполнять
запросы и обрабатывать большие объемы данных.
Для выполнения подобной обработки можно установить специализированное
ПО (например, Netezza или Microsoft SQL Server) на виртуальной машине или
же выбрать облачно-ориентированное решение (такое, как Snowlake). AWS
как публичная облачная платформа предоставляет решение Amazon Redshift
для хранения данных в петабайтовом масштабе, использующее столбцовый
формат и МРР. Вы больше узнаете об обработке данных и аналитике в главе 12
«Инженерия данных для архитектур решений».
Задача хранения и поиска в больших объемах данных возникает достаточно
часто — например, если требуется найти конкретную ошибку в журнале или по-
строить механизм поиска документов. Для таких задач приложение должно создать
функциональность поиска данных. Эта тема рассматривается в следующем разделе.
Построение функциональности поиска данных
Часто возникает необходимость быстро провести поиск по большому объему
данных, чтобы оперативно решить проблему или получить информацию для
бизнеса. Поиск в данных приложения поможет проанализировать детализиро-
ванную информацию с разных точек зрения. А чтобы провести поиск с низкой
задержкой и высокой пропускной способностью, понадобится поисковая система.
Elasticsearch — одна из самых популярных поисковых платформ, построенная
на основе библиотеки Apache Lucene — бесплатной библиотеки с открытым
исходным кодом, лежащей в основе многих популярных поисковых систем.
С помощью стека ELK (Elasticsearch, Logstash, Kibana) легко обрабатывать
крупномасштабные данные и индексировать их для автоматизации поиска. Эти
особенности помогли разработать на базе Elasticsearch многочисленные средства
визуализации и анализа. Например, Logstash использует Elasticsearch для сбора,
преобразования и анализа больших объемов журнальных данных приложений.
Kibana содержит встроенный соединитель с Elasticsearch и предоставляет
простое решение для создания дашбордов и анализа индексируемых данных.
Elasticsearch может развертываться на виртуальных машинах и масштабиро-
ваться горизонтально для повышения емкости за счет добавления новых узлов
в кластер. Публичная облачная платформа AWS предоставляет управляемый
Выбор технологии для оптимизации производительности 265
сервис Amazon OpenSearch, обеспечивающий бюджетное и простое масштаби-
рование и управление кластером Elasticsearch в облаке.
В этом разделе вы узнали о различных технологиях баз данных и о том, в каких
ситуациях они применяются. Приложения могут использовать разные техно-
логии баз данных в разных компонентах для достижения оптимальной произ-
водительности. Для сложных транзакций необходимо выбирать реляционную
базу данных OLTP, а для хранения и обработки неструктурированных или
полуструктурированных данных — нереляционную базу данных NoSQL. Ис-
пользуйте базу данных No SQL, когда очень низкая задержка необходима в не-
скольких географических регионах и когда требуется обрабатывать сложные
запросы на уровне приложения (например, в играх). А для крупномасштабного
анализа структурированных данных выбирайте базу данных OLAP.
Перейдем к следующему критически важному компоненту архитектуры — сети.
Сеть является опорой всего приложения и обеспечивает связь между серверами
и внешним миром. Давайте посмотрим, как сети влияют на производительность
приложения.
Повышение производительности сети
В эпоху доступности быстрого интернета приложения должны нормально ра-
ботать у каждого пользователя практически в каждом уголке мира. Любая за-
держка отклика системы зависит от нагрузки запросов и удаленности конечного
пользователя от сервера. Если система не будет быстро реагировать на запросы
пользователя, это может привести к цепной реакции: все ресурсы останутся
занятыми, а в системе накопится значительное количество необработанных
запросов, что приведет к снижению ее общей производительности.
Чтобы сократить задержку, смоделируйте местоположение и среду пользо-
вателя и выявите имеющиеся разрывы. Используя полученные результаты,
спроектируйте физическое местоположение сервера и механизм кэширования
для достижения минимальной задержки; впрочем, выбор сетевого решения для
приложения зависит от скорости сети, требований к пропускной способности
и задержке. Приложение с глобальной пользовательской базой должно иметь
быстрое соединение с пользователями, и место размещения играет важную
роль. Пограничные локации, предоставляемые CDN, помогут локализовать
расширенный контент и сократить общую задержку.
В главе 4 «Паттерны проектирования архитектур решений» вы узнали, как ис-
пользовать CDN для размещения данных рядом с пользователем (раздел «По-
строение архитектуры на базе кэша»). Существуют различные решения CDN
с обширной сетью пограничных локаций. Используйте CDN, если в приложении
много статического контента — например, если требуется предоставлять конеч-
ному пользователю большое количество графики и видео. Некоторые популяр-
ные решения CDN — Akamai, Cloudlare и Amazon CloudLront (предоставляется
облачной платформой AWS).
266 Глава 6. Факторы производительности
Граничные вычисления
Граничные вычисления (edge computing) — парадигма распределенных вычис-
лений, приближающая вычисления и данные к месту, где необходимо сократить
время отклика и сэкономить ресурсы канала связи. Они реализуются в мини-дата-
центрах, предоставляющих инфраструктуру ИТ рядом с местом их использования.
Граничные вычисления сформировались как нестандартная стратегия оптимизации
производительности приложений прежде всего там, где задержка, пропускная
способность и обработка данных в реальном времени критически важны. Можно
использовать граничные вычисления для повышения производительности при-
ложения, имеющего глобально-распределенную пользовательскую базу.
Представьте, что сайт всемирно известной глобальной социальной сети — такой,
как Facebook, X или TikTok — испытывает пик пользовательской активности
из-за события в реальном времени (например, решающего спортивного матча
или свежей новости о селебрити). В традиционной модели централизованным
серверам может понадобиться помощь для обработки наплыва запросов, что при-
ведет к замедлению загрузки и потенциальным нарушениям работоспособности.
На помощь приходят сети CDN; тут доминируют такие отраслевые гиганты, как
Akamai, Cloudlare, Imperva и Amazon CloudFront.
Akamai, один из пионеров в области CDN, имеет обширную сеть граничных
серверов, стратегически размещенных в странах и городах по всему миру.
Граничные серверы Akamai в Токио начинают работать, когда пользователь из
Токио (Япония) заходит на сайт глобальной социальной сети во время события
с высоким трафиком. Эти серверы кэшируют и поставляют часто запрашиваемый
контент (графику, видео, статические файлы) из точки, находящейся намного
ближе к пользователю, чем централизованные дата-центры. В результате поль-
зователь получает молниеносную загрузку, сокращенную задержку и плавную
поставку контента.
Кроме того, граничные серверы Akamai предоставляют расширенные средства
безопасности — например, защиту от DDoS-атак и функциональность WAF
(Web Application Firewall), обеспечивающие защиту сайта социальной сети от
кибератак и несанкционированного доступа. Сервис Amazon CloudFront, тесно
связанный с AWS (Amazon Web Services), также предоставляет надежное ре-
шение граничных вычислений для бизнесов всех размеров.
Помимо социальных сетей, граничные вычисления применяются и в других
отраслях. Например, в беспилотных автомобилях граничные устройства обраба-
тывают данные от датчиков в реальном времени, чтобы решения принимались за
доли секунды. Таким образом обеспечивается безопасность на дороге. В мире 1оТ
граничные вычисления позволяют умным устройствам анализировать данные
локально, сокращая задержку и экономя пропускную способность канала связи.
Например, умный термостат может регулировать температуру на основании
данных локальных датчиков без необходимости постоянного обмена данными
с централизованными серверами.
Выбор технологии для оптимизации производительности 267
В области здравоохранения граничные вычисления используются для дистан-
ционного наблюдения за пациентами. Носимые устройства, оснащенные функ-
циональностью граничной обработки, могут анализировать данные в реальном
времени и при возникновении отклонений отправлять оповещения медицинским
организациям или самим пациентам для своевременного вмешательства.
За счет смещения вычислений ближе к источникам данных и конечным пользо-
вателям граничные вычисления повышают производительность, отзывчивость
и масштабируемость, вследствие чего эта технология играет важную роль для
улучшения производительности приложения.
Рассмотрим теперь некоторые стратегии маршрутизации DNS для достижения
низкой задержки при глобальном развертывании приложения.
Определение стратегии маршрутизации DNS
Приложение можно развернуть в нескольких географических регионах, чтобы
обеспечить глобальный охват. Что касается пользовательских запросов, их
необходимо маршрутизировать к самому близкому и быстрому доступному
серверу для получения быстрого ответа от приложения. Маршрутизатор DNS
обеспечивает преобразование между доменными именами и IP-адресами. Таким
образом обеспечивается обслуживание запросов правильным сервером, когда
пользователь вводит доменное имя, — например, при вводе адреса amazon,
com в браузере запрос всегда направляется сервису DNS сервера приложения
Amazon.
AWS предоставляет сервис DNS, который называется Amazon Route 53.
В нем можно определять политики маршрутизации в зависимости от по-
требностей приложения. Amazon Route 53 предоставляет сервисы DNS для
упрощения управления доменом. Перечислим некоторые распространенные
политики маршрутизации.
• Простая политика маршрутизации: как подсказывает название, это самая
прямолинейная политика маршрутизации, без условий. Иногда бывает по-
лезно маршрутизировать трафик к одному ресурсу — например, веб-серверу,
используемому для отправки информации конкретному сайту.
• Политика маршрутизации для обработки отказов: эта политика требует обе-
спечить высокую доступность путем настройки конфигурации обработки от-
казов «активный — пассивный». Если приложение выходит из строя в одном
регионе, то весь трафик автоматически перенаправляется в другой регион.
• Политика маршрутизации с учетом геолокации: если пользователь отно-
сится к конкретному региону, можно воспользоваться политикой с учетом
геолокации. Она направляет трафик в конкретный регион.
• Политика маршрутизации с учетом географической близости: имеет много
общего с политикой с учетом геолокации, но трафик может перемещаться
в ближайшие местоположения в случае необходимости.
268 Глава 6. Факторы производительности
• Политика маршрутизации на базе задержки: если приложение работает
в нескольких регионах, можно воспользоваться политикой на базе за-
держки для обслуживания трафика из региона, в котором задержка наи-
меньшая.
• Взвешенная политика маршрутизации: используется для А/В-тестирования,
когда определенная часть трафика должна направляться в отдельный регион
и расширяться по мере успешности тестирования.
Также Amazon Route 53 может обнаруживать аномалии в источнике и объеме
запросов DNS и назначать повышенный приоритет запросам от заведомо на-
дежных пользователей. Кроме того, этот сервис защищает приложение от
DDoS-атак.
После прохождения через сервер DNS в большинстве случаев далее трафик про-
ходит через балансировщик нагрузки, который распределяет трафик по кластеру
серверов. Балансировщики нагрузки рассматриваются в следующем разделе.
Применение балансировщика нагрузки
Балансировщики нагрузки распределяют сетевой трафик между серверами для
повышения конкурентности, надежности и уменьшения задержки. Баланси-
ровщики нагрузки могут быть физическими или виртуальными и должны соот-
ветствовать потребностям приложения. Обычно в приложениях используются
два типа балансировщиков.
• Сетевой балансировщик нагрузки (балансировщик нагрузки 4-го уровня):
маршрутизирует пакеты на основании информации из заголовка пакета —
например, IP-адресов и портов источника/приемника. Балансировщик на-
грузки уровня 4 не анализирует содержимое пакета, вследствие чего требует
менее интенсивных вычислений, чем балансировщик нагрузки 7-го уровня
(уровня приложения), и потому работает быстрее. Сетевой балансировщик
нагрузки может обрабатывать миллионы запросов в секунду.
• Балансировщик нагрузки приложения (балансировщик нагрузки 7-го
уровня): анализирует и маршрутизирует пакеты на основании их полного со-
держимого. Уровень 7 используется в сочетании с запросами HTTP. Решения
маршрутизации принимаются на основании таких факторов, как заголовки
HTTP, путь URI и тип контента. Этот способ позволяет использовать более
мощные правила маршрутизации, но маршрутизация пакетов занимает боль-
ше времени. Балансировщик нагрузки может маршрутизировать запросы
контейнерам в кластере на основании их номера порта.
В зависимости от среды можно выбрать аппаратные балансировщики нагруз-
ки — например, F5 или Cisco. Также можно использовать программный балан-
сировщик нагрузки — такой, как Nginx.
AWS предоставляет управляемый виртуальный балансировщик нагрузки
Amazon ELB (Elastic Load Balancing). ELB может применяться на уровне 7 как
балансировщик нагрузки приложения и на уровне 4 как сетевой.
Выбор технологии для оптимизации производительности 269
Балансировщик нагрузки предоставляет превосходную возможность защиты
приложения и обеспечения его высокой доступности за счет отправки запросов
только работоспособным экземплярам. Он работает в сочетании с автомасшта-
бированием для добавления или удаления экземпляров по мере необходимости.
Рассмотрим механизм автомасштабирования и его возможности для повышения
производительности и обеспечения высокой доступности приложений.
Применение автомасштабирования
Механизм автомасштабирования рассматривался в главе 2 «Принципы про-
ектирования архитектур решений». В разделе «Построение масштабируемых
архитектур» вы узнали об упреждающем и реактивном автомасштабировании.
Концепция автомасштабирования стала особенно популярной с распространени-
ем адаптивности, обеспечиваемой облачными вычислительными платформами.
Облачная инфраструктура позволяет быстро масштабировать парк серверов
в зависимости от пользовательских запросов или потребностей в ресурсах.
С публичной облачной платформой — такой, как AWS — автомасштабирование
можно применять на каждом уровне архитектуры. Парк веб-серверов можно
масштабировать на основании количества запросов на уровне представления,
а уровень приложения — на основании памяти сервера и степени нагрузки про-
цессора. Также можно выполнять плановое масштабирование, если известны
шаблоны трафика при повышении нагрузки на сервер. На уровне баз данных
автомасштабирование доступно для таких реляционных баз данных, как Amazon
Aurora Serverless и Microsoft Azure SQL Database. Базы данных NoSQL — такие,
как Amazon DynamoDB — могут автоматически масштабироваться на основании
пропускной способности.
Для автомасштабирования необходимо задать количество экземпляров серверов.
Ваша задача — определить максимальную и минимальную емкость серверов
в контексте потребностей приложения в масштабировании. На рис. 6.6 для при-
мера изображена страница конфигурации автомасштабирования в облаке AWS.
Такая конфигурация, при условии стандартной работы трех экземпляров веб-
сервера, может масштабироваться с расширением до пяти экземпляров, если загруз-
ка процессоров на серверах превышает 50 %, или со сжатием до двух экземпляров,
если загрузка падает ниже 20 %. Если экземпляр становится неработоспособным
в стандартном сценарии, общее количество экземпляров падает ниже оптимального.
В таком случае балансировщик нагрузки отслеживает работоспособность экзем-
пляра и использует автомасштабирование для предоставления новых экземпляров.
Автомасштабирование — полезная возможность, но оно требует задания соот-
ветствующей конфигурации, чтобы ограничить затраты при изменении нагрузки
на процессор. Автомасштабирование может значительно повысить затраты
в случае непредвиденного выброса трафика, обусловленного DDoS-атакой.
Защитите свою систему от таких инцидентов. Подробнее о способах защиты
можно узнать в главе 7 «Факторы безопасности».
270 Глава 6. Факторы производительности
Edit details - ASG-SA
X
Launch Instances Using ф
О Launch Template
О Launch Configuration
Launch Configuration ф f websarverCopy
Desired Capacity ф
Min ®
Max ф
Availability Zone(9} ф
Subnets) ф
| teatec2-6Aolb-lOE7VQ7XZAOVB x'
Classic Load Balancers ф
Target Groups ф
Health Check Type ф
Health Check Grace Period ф
Instance Protection ф
300
Cancel
Save
Рис. 6.6. Конфигурация автомасштабирования
В этом разделе вы узнали о различных сетевых компонентах, которые помогают
улучшить производительность приложения. Сетевой трафик приложения можно
оптимизировать с учетом местоположения пользователя и потребностей при-
ложения. Так как мобильные интерфейсы становятся основными для многих
приложений, следует проводить проактивный мониторинг производительности
мобильных приложений, чтобы повысить качество взаимодействия с пользо-
вателями. Теме факторов производительности для мобильных приложений
посвящен следующий раздел.
Факторы производительности для мобильных приложений 271
Факторы производительности для мобильных
приложений
Мобильные приложения стали неотъемлемой частью многих цифровых плат-
форм. В наше время пользователи чаще заходят в мобильное приложение, а не
на сайт с десктопного компьютера. Более того, значительная часть пользователь-
ского трафика приходится именно на мобильные приложения, поэтому очень
важно позаботиться о том, чтобы они имели высокую производительность. Так
как мобильные приложения превращаются в основу наших цифровых взаимо-
действий, приоритетом становится обеспечение их производительности, без-
опасности и удобства использования. Рассмотрим некоторые лучшие практики
разработки эффективных мобильных приложений.
Оптимизация времени загрузки
В мобильных приложениях время загрузки становится критически важным
фактором, который способен как повысить вовлеченность пользователей, так
и, наоборот, разочаровать их. Быстрая и эффективная загрузка чрезвычайно
важна, особенно если вспомнить, что пользователи чаще используют прило-
жения на ходу и ожидают ответа немедленно. Некоторые способы сокращения
времени загрузки основаны на оптимизации размеров изображений, применении
отложенной загрузки элементов и ускорении загрузки изначально видимых
элементов.
Эффективное использование ресурсов
Ограниченность ресурсов (процессора, памяти, заряда батареи) означает ограни-
ченность потенциала мобильных устройств. Чтобы приложение работало плавно
и не расходовало ресурсы устройства, разработчики должны сознательно свести
к минимуму использование ресурсов. Для этого существуют разные стратегии:
эффективные алгоритмы, сокращение утечек памяти за счет управления выделе-
нием памяти и оптимизация запросов для выборки только необходимых данных.
Отзывчивость пользовательского интерфейса (UI)
Пользовательский интерфейс должен быть интуитивно понятным и отзывчивым,
чтобы пользователь при вводе данных немедленно получал обратную связь. Для
этого любой процесс с интенсивными вычислениями (например, получение
данных или обработка изображений) должен выполняться в фоновом режиме,
чтобы он не препятствовал UI-взаимодействиям. Применение асинхронного
программирования и многопоточности сохранит адаптивность и отзывчивость
пользовательского интерфейса.
272 Глава 6. Факторы производительности
Эффективность сети
С учетом потенциала нестабильных или медленных сетевых подключений в мо-
бильных средах приложение должно эффективно управлять сетевыми запросами.
Реализация кэширования для данных, которые изменяются нечасто, оптими-
зация вызовов API и корректная обработка сетевых сбоев с предоставлением
соответствующей обратной связи пользователю могут значительно улучшить
впечатления пользователя и производительность приложения.
Расход заряда батареи
Приложение, которое интенсивно расходует заряд батареи, быстро перестает
привлекать пользователей. Необходимо учитывать процессы оптимизации
и управление фоновыми задачами для минимизации потребления энергии. Сле-
дите за тем, чтобы GPS, Bluetooth и другие процессы, интенсивно расходующие
заряд, использовались разумно и отключались, когда они не нужны.
Кросс-платформенная совместимость
На рынке представлены самые разные устройства, операционные системы и разме-
ры экранов, поэтому приложение должно поддерживать высокую производитель-
ность на разных платформах. Использование фреймворков кросс-платформенной
разработки и тщательное тестирование приложения на разных устройствах
обеспечит последовательное и оптимальное взаимодействие с пользователями.
UX-дизайн
Бесшовное и интуитивное взаимодействие с пользователем (UX, User
experience) — ключевой фактор успеха любого приложения. UX включает
дизайн, ориентированный на пользователя, обеспечение простоты навигации
и поддержание логики операций в приложении, чтобы пользователи могли
выполнять нужные действия с минимальными усилиями.
Эффективное управление данными
Чтобы пользователи могли получать актуальную информацию без ущерба для
производительности, важно обеспечить эффективное управление данными за
счет выбора локального хранилища для часто используемых данных, а также
бесшовную синхронизацию между локальными данными и данными, получа-
емыми дистанционно.
Тестирование и контроль качества
Реализация жестких протоколов тестирования, включающих тестирование произ-
водительности в разных условиях и на разных устройствах, гарантирует, что при-
ложение сможет обеспечить оптимальную производительность даже при высокой
Тестирование производительности 273
нагрузке. Применение автоматизированного тестирования и непрерывной инте-
грации может помочь выявить и быстро исправить проблемы на этапе разработки.
Конструирование высокопроизводительных мобильных приложений подразу-
мевает гармоничное сочетание ориентированности на пользователя и техни-
ческой компетенции. Тщательно оптимизируя каждую грань приложения, от
интерфейса и времени загрузки до управления данными и средств безопасности,
разработчики могут добиться того, что приложение будет хорошо работать
в разных условиях и на разных устройствах. При реализации разных стратегий
для улучшения производительности приложения всегда рекомендуется их тща-
тельно тестировать. В следующем разделе тестирование производительности
рассматривается более подробно.
Тестирование производительности
Тестирование производительности — важнейший тип тестирования программных
продуктов, проверяющий, что приложение будет хорошо работать при разных
рабочих нагрузках. Центральное место в нем занимает оценка стабильности, ско-
рости, отзывчивости и масштабируемости приложения в разных условиях. Тести-
рование производительности не выявляет ошибки или дефекты; оно определяет,
как приложение будет реагировать на разные уровни потребностей. А с учетом
того, что современные пользователи привыкли к плавным и быстрым приложе-
ниям, тестирование производительности еще никогда не было столь важным.
Трудно переоценить, насколько в цифровую эпоху важна эффективная работа
приложений. Прежде всего она напрямую влияет на удовлетворенность пользова-
теля. Заторможенность или частые сбои могут отбить интерес к приложению. Ни-
кто не захочет тратить время на приложение, которое не может быстро выдавать
результат, особенно при высокой нагрузке или во время пиков использования.
Неудовлетворенность в таких случаях может привести к тому, что пользователь
полностью откажется от вашего продукта и отдаст предпочтение конкурентам.
Представьте популярный интернет-магазин, который готовится к «черной
пятнице». На сайт придут тысячи, если не миллионы потенциальных покупа-
телей, поэтому очень важно позаботиться о том, чтобы система работала без
сбоев, транзакции обрабатывались быстро, а пользовательские взаимодействия
оставались гладкими даже при пике посещений. В данном случае тестирование
производительности не просто полезно, а необходимо.
Виды тестирования производительности
Для каждого из параметров производительности существует своя разновидность
тестирования. Ниже приведена их краткая сводка.
• Нагрузочное тестирование: эта разновидность тестирования дает представ-
ление о том, как система поведет себя под ожидаемыми, реальными нагруз-
ками. Его можно сравнить с тестированием моста, на который постепенно
274 Глава 6. Факторы производительности
добавляется вес, пока он не достигнет предполагаемого максимального
количества автомобилей. Например, если сайт интернет-магазина ожидает
10 000 посетителей во время праздничной распродажи, нагрузочное тести-
рование должно имитировать эти 10 000 посетителей, чтобы проверить, что
сайт будет нормально работать в таких условиях.
• Стрессовое тестирование: представьте, что вы втиснули в лифт нескольких
человек, превысив его допустимую нагрузку, чтобы узнать, будет он рабо-
тать или сломается. В этом заключается суть стрессового тестирования. Оно
должно довести системы до предельных значений и проверить, что даже
в худших сценариях сбои не приведут к катастрофическим последствиям.
Например, банковское приложение необходимо подвергнуть стрессовому
тестированию, чтобы узнать, как оно себя поведет, если в него попытаются
одновременно войти 1 000 000 пользователей (что значительно превышает
обычный трафик).
• Тестирование на выносливость: эта разновидность тестирования отвечает на
вопрос, сможет ли система эффективно работать под ожидаемой нагрузкой
в течение продолжительного времени. Например, потоковый сервис можно
подвергнуть тестированию на выносливость, чтобы убедиться, что он способен
все выходные непрерывно транслировать фильмы и сериалы в потоковом
режиме без снижения качества или скорости.
• Пиковое тестирование: в реальных условиях пользовательский трафик может
быть непредсказуемым. Пиковое тестирование можно сравнить с проверкой
того, как поведет себя электросеть, если во время жары все пользователи
вдруг одновременно включат кондиционеры. Например, пиковое тестиро-
вание может проверять поведение новостного сайта, если во время крупного
мероприятия (скажем, Олимпийских игр) множество пользователей начнут
проверять итоги футбольного матча.
• Объемное тестирование: в этом виде тестирования первоочередное внимание
уделяется данным. Его можно сравнить с проверкой того, насколько хорошо
библиотека справится с упорядочением и выдачей миллионов книг. Для при-
ложения с базой данных объемное тестирование может проверять поведение
системы, если в базе данных хранятся миллиарды записей. Другой пример —
проверка глобальным сервисом электронной почты отзывчивости своей
системы при поиске по колоссальному количеству хранимых сообщений.
Существует много программных инструментов тестирования производительно-
сти — например, JMeter, LoadRunner и WebLoad. Эти системы имитируют раз-
личные сценарии и нагрузки для тестирования производительности приложения.
Тестирование производительности играет важнейшую роль в жизненном цикле
разработки. Проверка отказоустойчивости, надежности и скорости приложения
критична для его успешной работы в реальных условиях.
Тестирование и мониторинг производительности — два важнейших аспекта
обеспечения эффективности и надежности приложения, но они служат разным
Мониторинг производительности 275
целям на стадиях разработки и развертывания. Тестирование производитель-
ности предназначено для выявления потенциальных проблем с производи-
тельностью до того, как они повлияют на пользователей, тогда как мониторинг
производительности обеспечивает контроль за производительностью системы
и быстрый отклик на любые проблемы, возникающие после развертывания.
Мониторинг производительности более подробно рассматривается в следую-
щем разделе.
Мониторинг производительности
Мониторинг производительности особенно важен для проактивного предотвра-
щения возможных последствий проблем с производительностью для конечного
пользователя.
Определите эталонный показатель производительности и настройте отправку
оповещений команде в случае его нарушения — например, время загрузки мо-
бильного приложения не должно превышать трех секунд. Оповещение должно
инициировать автоматизированное ответное действие на проблему с недоста-
точно эффективными компонентами — например, добавление дополнительных
узлов в кластер веб-приложения для снижения запросной нагрузки.
Существуют разные средства мониторинга, которые измеряют производитель-
ность приложения и инфраструктуры в целом. Вы можете воспользоваться
сторонними инструментами (например, Splunk) или предоставляемым AWS
сервисом Amazon CloudWatch для мониторинга любого приложения.
Решения мониторинга можно разделить на две категории — для активного
и пассивного мониторинга.
• При активном мониторинге вы имитируете пользовательскую активность
и выявляете нехватку производительности заранее. Данные приложений и ра-
бочая нагрузка постоянно изменяются, требуя непрерывного упреждающего
мониторинга. Активный мониторинг работает наряду с пассивным, когда
вы запускаете известные возможные сценарии для воспроизведения поль-
зовательских взаимодействий. Активный мониторинг должен проводиться
во всех средах разработки, тестирования и эксплуатации для обнаружения
любых проблем, прежде чем они появятся у пользователя.
• Пассивный мониторинг выявляет неизвестные закономерности в реальном
времени. Для приложений на базе веб-технологий пассивный мониторинг
подразумевает получение у браузера важнейших метрик, которые могут
указывать на проблемы с производительностью. Это метрики, связанные
с геолокацией пользователей, типами браузеров и устройств, которые
помогают понять пользовательские взаимодействия и географическую
эффективность. Мониторинг основан на работе с данными и включает
такие процессы, как поглощение, обработка и визуализация больших
объемов данных.
21Ь Глава 6. Факторы производительности
Производительность никогда не дается даром, и вы, как архитектор решения,
должны продумать возможные компромиссы, чтобы выбрать правильный подход.
Внутренние приложения организации (скажем, продукты для учета рабочего
времени и для потребностей отдела управления персоналом) могут не требовать
такой высокой производительности, как внешние продукты (например, при-
ложения интернет-магазинов). С другой стороны, приложение для биржевой
торговли требует очень высокой производительности, что приводит к большим
затратам. Старайтесь соблюдать баланс надежности, согласованности, затрат
и производительности, соответствующий потребностям вашего приложения.
В дальнейших главах мы продолжим изучать методы и инструменты монито-
ринга, а в главе 8 «Факторы надежности архитектуры» подробнее поговорим
о мониторинге и оповещениях.
Отслеживание и повышение производительности — сложные задачи, для кото-
рых приходится собирать огромное количество данных и анализировать зако-
номерности. Закономерности доступа позволяют принять правильное решение
в части оптимизации производительности. Применение непрерывного активного
мониторинга в сочетании с пассивным мониторингом помогает поддерживать
стабильную производительность приложений.
Итоги
В этой главе вы узнали о принципах архитектурного проектирования, влияющих
на производительность приложений. Мы рассказали о задержке и пропускной
способности на разных уровнях архитектуры и о том, как связаны эти харак-
теристики.
Для высокопроизводительных приложений необходимо обеспечить низкую
задержку и высокую пропускную способность на каждом уровне архитектуры.
Конкурентность помогает обрабатывать большое количество запросов. Вы
узнали, чем параллелизм отличается от конкурентности, и получили представ-
ление о том, как кэширование помогает улучшить общую производительность
приложения.
Затем мы обсудили, как выбрать технологию и ее рабочие модели, обеспечиваю-
щие желаемую производительность приложения. При рассмотрении возможных
вычислительных ресурсов были описаны типы процессоров и различия между
ними, которые помогают принять правильное решение при выборе экземпляров
серверов. Мы поговорили о контейнерах и о том, как они помогают эффектив-
но использовать ресурсы и в то же время повышают производительность. Вы
также узнали, как Docker и Kubernetes работают совместно и какое место они
занимают в архитектурах.
В разделе, посвященном выбору технологии хранения, были рассмотрены
разные виды хранилищ (блоковые, файловые, объектные) и различия между
ними, а также доступные варианты хранения в локальных и облачных средах.
Итоги 277
В разделе, посвященном выбору базы данных, вы узнали о различных типах баз
данных, включая реляционные и нереляционные БД, а также информационные
хранилища. Также были представлены различные стратегии маршрутизации
запросов, которые помогают снизить сетевую задержку для пользователей из
разных геолокаций. Мы обсудили, как балансировщики нагрузки и автомас-
штабирование помогают обслуживать множество пользовательских запросов
без ущерба для производительности приложения. Так как для любых проектов
важны мобильные версии, мы описали факторы производительности для мо-
бильных приложений. Мы подчеркнули, как важно проводить тестирование
производительности и мониторинг приложений, чтобы получать информацию
о производительности.
В следующей главе вы узнаете, как защитить приложения с помощью аутенти-
фикации и авторизации. Эти механизмы обеспечивают защиту данных как при
хранении, так и при передаче, а также защиту приложения от всевозможных угроз
и атак. Также мы раскроем такие темы, как аудит безопасности, оповещения,
мониторинг и автоматизация.
ГЛАВА 7
ФАКТОРЫ БЕЗОПАСНОСТИ
Безопасность всегда занимает центральное место в дизайне архитектуры. Многие
предприятия терпят убытки из-за брешей в безопасности, ведущих к утечкам
клиентских данных. В таких ситуациях можно потерять не только доверие
клиентов, но и весь бизнес.
Существует множество отраслевых стандартов и нормативов, призванных гаран-
тировать, что приложение безопасно, а конфиденциальные данные защищены.
В предыдущей главе вы узнали о возможностях повышения производительности
и выборе подходящей технологии для архитектуры. В этой главе будут рассмо-
трены лучшие практики защиты приложений и обеспечения его соответствия
отраслевым стандартам.
Безопасность в архитектуре означает не только защиту границ рабочей ИТ-
нагрузки. Необходимо также позаботиться о том, чтобы разные части инфра-
структуры приложения были защищены друг от друга. Например, на сервере
можно использовать файрвол, который будет управлять тем, какие данные могут
входить в систему или выходить из нее и куда эти данные могут направляться.
При таком подходе возникновение проблем безопасности в одной части не по-
влияет на другие. То же самое необходимо сделать для других частей, включая
данные и программы. Безопасность должна применяться на каждом уровне и для
каждого компонента архитектуры.
Мы поговорим также о защите облачных систем.
В этой главе рассматриваются следующие практики безопасности.
• Принципы проектирования безопасной архитектуры.
• Выбор технологии для безопасности архитектуры.
• Безопасность и сертификация соответствия.
• Модель общей ответственности за безопасность в облаке.
• Моделирование угроз безопасности.
Принципы проектирования безопасной архитектуры
279
Принципы проектирования
безопасной архитектуры
Принципы безопасности служат для защиты системы и информации при предо-
ставлении коммерческой ценности клиентам. Недостаточный уровень безопас-
ности может серьезно отразиться на клиентах и бизнесе.
Для непрерывного ведения бизнеса необходимо провести углубленную оценку
рисков безопасности и спланировать стратегию их снижения. В следующих
разделах будут рассмотрены стандартные принципы проектирования, которые
способствуют укреплению безопасности архитектуры.
Аутентификация и авторизация
Цель аутентификации — определить, может ли пользователь получить доступ
к системе с предоставленными регистрационными данными, тогда как автори-
зация определяет, что может делать пользователь после входа в систему.
Создайте централизованную систему для управления аутентификацией и ав-
торизацией пользователей. Централизованная система управления пользова-
телями помогает отслеживать их операции, чтобы вы могли деактивировать
пользователей, когда они перестают быть частью системы или начинают делать
что-то неправомерное. Можно определить стандартные процедуры создания
нового пользователя и лишения доступа для неактивных пользователей. Цен-
трализованная система устраняет зависимость от учетных данных с длительным
сроком действия и позволяет настроить другие методы безопасности — такие,
как ротация паролей.
Авторизацию следует строить по принципу наименьших привилегий — он
означает, что пользователи изначально не имеют никаких прав доступа и им
назначаются только те типы доступа, которые необходимы для выполнения
ими своей работы. Создание групп доступа в соответствии с рабочими ролями
позволяет управлять политикой авторизации в одном месте и применять огра-
ничения авторизации к большому количеству пользователей. Например, мож-
но предоставить группе разработки полный доступ к среде разработки и доступ
только для чтения к рабочей среде. Если в компании появляется новый раз-
работчик, он должен быть добавлен в группу разработки, где осуществляется
централизованное управление всеми политиками авторизации.
Включение системы единого входа (SSO, Single Sign-On) с централизованным
репозиторием пользователей избавляет от необходимости хранить множество
паролей для пользовательской базы и устраняет риск утечки паролей. Интегра-
ция многофакторной аутентификации (MFA, multi-factor authentication) с SSO
добавляет дополнительный уровень защиты. По условиям MFA пользователь
должен предъявить два и более доказательства верификации (маркер безопас-
ности, отпечаток пальца, распознавание лица и т. д.), чтобы получить доступ
к ресурсу.
280 Глава 7. Факторы безопасности
Большие организации используют централизованные средства управления
пользователями (такие, как Active Directory) в целях аутентификации и автори-
зации сотрудников для предоставления доступа к внутренним корпоративным
приложениям: системам управления персоналом, учета затрат, учета рабочего
времени и т. д.
В приложениях, обращенных к клиенту, — например, интернет-магазинах
и сайтах социальных сетей — можно использовать систему аутентификации
OpenlD для управления централизованной системой. OpenlD — протокол
аутентификации, основанный на открытых стандартах.
Повсеместное применение безопасности
Часто организации направляют основные усилия на обеспечение физической
безопасности дата-центров и защиту внешнего сетевого уровня от атак. Не огра-
ничивайтесь внешним уровнем и позаботьтесь о том, чтобы безопасность при-
менялась на каждом уровне приложения.
Применяйте принцип защиты в глубину (DiD, Defense-in-Depth) для органи-
зации уровней безопасности в приложении; например, веб-приложение долж-
но быть защищено от внешнего интернет-трафика при помощи сетей EDGE
(Enhanced Data rates for Global Evolution) и маршрутизации DNS (Domain
Name System). Применяйте средства безопасности на уровне балансировщика
нагрузки и сетевом уровне для блокировки вредоносного трафика.
Защищайте каждый экземпляр приложения, разрешая только необходимый
входящий и исходящий трафик в веб-приложении и на уровне базы данных.
Защищайте операционные системы антивирусными программами для предот-
вращения атак. Применяйте упреждающие и реактивные меры защиты за счет
размещения системы обнаружения вторжений (IDS, Intrusion Detection System)
и системы предотвращения вторжений (IPS, Intrusion Prevention System)
перед потоком трафика; используйте файрвол веб-приложения (WAF, Web
Application Firewall) для защиты приложений от разнообразных атак. Средства
безопасности более подробно рассматриваются в разделе «Выбор технологии
для безопасности архитектуры» этой главы.
Сокращение радиуса поражения
При применении мер безопасности на всех уровнях следует изолировать систе-
му в небольшой ячейке для сокращения радиуса поражения. Если атакующий
получит доступ к одной части системы, нарушение безопасности должно быть
ограничено наименьшей возможной областью приложения. Например, в веб-
приложении балансировщик нагрузки должен находиться в отдельной сети от
других уровней архитектуры, так как он будет иметь выход в интернет. Кроме
того, применяйте разделение сетей на уровне веб-приложения, приложения
Принципы проектирования безопасной архитектуры
281
и базы данных. Если атака произойдет на одном уровне, предотвратите ее рас-
пространение на другие уровни архитектуры.
Эти же правила распространяются на систему авторизации: предоставляйте
пользователям наименьшие привилегии и минимально необходимый уровень
доступа. Реализуйте MFA, чтобы даже при нарушении ограничений пользова-
тельского доступа атакующему всегда приходилось преодолевать второй уровень
аутентификации для получения доступа к системе.
Предоставляйте минимальный доступ, чтобы атакующий не имел доступа ко
всей системе; назначайте временные регистрационные данные, чтобы доступ
оставался открытым только на короткое время. Примите меры предосторож-
ности при предоставлении программного доступа, создав маркер безопасности
с частой ротацией ключей.
Постоянный мониторинг и аудит
Вся активность в системе должна регистрироваться в журналах, и необходи-
мо проводить их регулярный аудит. Многие отраслевые нормативы требуют
наличия аудита. Собирайте данные журналов от всех компонентов, включая
все транзакции и все вызовы API, и организуйте централизованную систему
мониторинга. Рекомендуется добавить уровень безопасности и установить
ограничения доступа к централизованной учетной записи журнала, чтобы никто
не мог вмешаться в ее работу.
Действуйте проактивно и будьте готовы обработать любой инцидент до того,
как он повлияет на пользователя. Оповещения и централизованный монито-
ринг помогут быстро принять меры и подавить последствия любого инцидента.
Отслеживайте всю пользовательскую активность и учетные записи приложения,
чтобы ограничить нарушения безопасности.
Повсеместная автоматизация
Автоматизация играет важную роль для быстрого исправления любых наруше-
ний безопасности. Она может использоваться для отмены изменений в конфи-
гурациях и оповещения команды безопасности — например, если кто-то добавил
в систему пользователей с привилегиями администраторов и открыл файрвол на
несанкционированном порте или IP-адресе. Автоматизация позволяет устранить
подобные нежелательные изменения в системе.
©Применение автоматизации в системах безопасности приобрело
популярность в концепции DevSecOps. Суть DevSecOps заключается во
включении безопасности в каждую часть разработки приложения и операций.
Концепция DevSecOps более подробно рассматривается в главе 11 «DevOps
и фреймворк архитектуры решений».
282 Глава 7. Факторы безопасности
Создавайте защищенные архитектуры и реализуйте средства безопасности,
которые определяются и управляются так же, как код. Можно использовать
средства безопасности с системой контроля версий и анализировать изменения
по мере необходимости. Автоматизированные механизмы безопасности в форме
программного кода предоставляют возможность более быстрого и экономичного
масштабирования операций безопасности.
Защита данных
Данные занимают центральное место в архитектуре, поэтому их защита чрез-
вычайно важна. Большинство действующих нормативов безопасности предна-
значено для защиты клиентских и идентификационных данных. Значительная
часть атак направлена на похищение пользовательских данных.
Классифицируйте данные по уровню безопасности и защитите их соответ-
ствующим образом. Например, информация о кредитной карте клиента относится
к самым чувствительным данным, и работать с ней необходимо с исключительной
осторожностью. А такие данные, как имя клиента, не настолько секретны и не
требуют самого высокого уровня защиты.
Защита данных на протяжении их жизненного цикла чрезвычайно важна для
поддержания их конфиденциальности, целостности и доступности. Данные могут
существовать в трех состояниях, причем каждое из них требует конкретных мер
безопасности для обеспечения комплексной защиты.
• Хранимые данные: данные, хранящиеся на физическом носителе (жестком
диске сервера, ноутбуке, USB-накопителе или в облачном хранилище).
Один из возможных механизмов защиты для хранимых данных — шиф-
рование — гарантирует, что, даже если носитель попадет в посторонние
руки, данные останутся недоступными без ключа шифрования. Кроме
того, необходимо установить средства управления доступом и регулярно
проводить аудиты, чтобы к данным могли обращаться только авторизо-
ванные пользователи.
• Передаваемые данные: данные, перемещающиеся по сети (с компьютера
пользователя на сервер, между серверами или в интернете). Чтобы защи-
тить данные при передаче, можно воспользоваться такими протоколами
шифрования, как TLS (Transport Layer Security). Эта мера гарантирует, что,
даже если данные будут перехвачены в ходе передачи, атакующий не сможет
прочитать их.
• Используемые данные: часто защита этого состояния сложнее всего, потому
что данные обрабатываются или используются приложениями. Шифрование
может защищать данные при хранении и передаче, но данные, загруженные
в память и используемые приложением, хранятся в виде простого текста и по-
тенциально уязвимы. Сейчас появляются новые технологии защиты использу-
емых данных — например, TEE (Trusted Execution Environment — доверенная
Выбор технологий для безопасности архитектуры 283
среда выполнения) и гомоморфное шифрование. Они позволят выполнять
операции с зашифрованными данными без их предварительного дешифро-
вания.
Создайте механизмы и инструменты, минимизирующие необходимость в прямых
обращениях к данным. Избегайте ручной обработки данных за счет применения
инструментальной автоматизации, исключающей человеческие ошибки, осо-
бенно при работе с конфиденциальными данными. Применяйте ограничения
доступа к данным там, где это возможно, для сокращения риска потери или
модификации данных.
После классификации данных по уровню конфиденциальности можно восполь-
зоваться необходимыми средствами шифрования, выделения базовых элементов
и управления доступом для защиты данных. Данные должны защищаться не
только при хранении, но и при передаче по сети. Различные механизмы защиты
данных также будут рассмотрены в разделе «Безопасность данных» этой главы.
Ответ на инциденты безопасности
Будьте готовы к любым происшествиям в области безопасности. Создайте про-
цесс управления инцидентами как часть требований политики организации.
Управление инцидентами может различаться в зависимости от организации
и приложения. Например, если приложение работает с персональной инфор-
мацией клиентов (РП, personally identifiable information), ответ на инциденты
безопасности потребует более жестких мер безопасности. С другой стороны,
если приложение обрабатывает небольшие объемы чувствительных данных
(например, приложение учета складских запасов), то в нем можно использовать
другой подход.
Обязательно смоделируйте инцидент, чтобы увидеть, как будет на него реаги-
ровать ваша команда безопасности. Она должна использовать средства автома-
тизации для ускорения обнаружения, анализа и ответа на любые происшествия
безопасности. Выработайте механизмы оповещений, мониторинга и аудита для
анализа первопричин, чтобы инциденты не повторялись.
В этом разделе вы узнали об общих принципах безопасности, которые необходи-
мо соблюдать в архитектуре для безопасности приложения. В следующем разделе
вы узнаете, как применять эти принципы с разными инструментами и методами.
Выбор технологий для безопасности
архитектуры
В предыдущем разделе основное внимание уделялось общим правилам без-
опасности, которые необходимо учитывать при проектировании архитектуры.
Тем не менее остается важный вопрос: как применять эти правила, чтобы обес-
печить безопасность приложения во время его реальной работы? Существуют
284 Глава 7. Факторы безопасности
различные инструменты и методы для каждого уровня приложения, которые
помогут сделать его безопасным.
В этом разделе подробно рассматриваются разные варианты технологий из
области управления пользователями и защиты веб-уровня, инфраструктуры
и данных приложения. Начнем с идентификационных данных пользователей
и управления доступом.
Идентификационные данные пользователей
и управление доступом
Идентификационные данные пользователей и управление доступом — важ-
нейшие параметры информационной безопасности. Это объясняется тем, что
доступ к ресурсам системы должны получать только пользователи, прошедшие
авторизацию и аутентификацию.
Управление пользователями может стать непростой задачей с ростом органи-
зации и расширением пользовательской базы продукта. Механизм управления
пользовательским доступом должен различать сотрудников организации, по-
ставщиков и клиентов и управлять доступом для каждой категории.
К категории корпоративных пользователей могут относиться сотрудники ор-
ганизации, подрядчики или поставщики. Это пользователи-специалисты с осо-
быми привилегиями разработки, тестирования и развертывания приложения.
Кроме того, им может понадобиться доступ к другим корпоративным системам
для выполнения повседневной работы — например, к системе управления ре-
сурсами предприятия (ERP, Enterprise Resource System), системе начисления
заработной платы, управления персоналом, приложению учета рабочего вре-
мени и т. д. С ростом организации количество пользователей может возрасти
от сотен до тысяч.
Конечными пользователями являются клиенты, которые используют приложе-
ния и обладают доступом для исследования и практического применения нужной
функциональности — например, игроки в игровом приложении, пользователи
в приложении социальной сети или покупатели на сайте интернет-магазина.
С ростом популярности продукта количество таких пользователей может ис-
числяться тысячами и даже миллионами. Установите особые меры безопасности
при открытии приложению доступа к внешнему интернет-трафику, чтобы за-
щитить приложение от угроз.
Начнем с управления корпоративными пользователями. Вам понадобится
централизованный репозиторий для соблюдения таких политик безопасности,
как создание надежных паролей, ротация паролей и MFA для улучшенного
управления пользователями. MFA предоставляет дополнительные средства
проверки личности пользователя, если пароль мог быть взломан. Среди по-
пулярных поставщиков MFA можно выделить Google Authenticator, Gemalto,
YubiKey, RSA SecurlD, Duo и Microsoft Authenticator.
Выбор технологий для безопасности архитектуры 285
С точки зрения пользовательского доступа аутентификация на основе ролей
(RBA, Role-Based Authentication) упрощает управление пользователями; она
позволяет создавать пользовательские группы для ролей пользователей и назна-
чать соответствующие им политики доступа. Как показано на рис. 7.1, в системе
можно определить три группы (администраторы, разработчики и тестировщики),
с назначением каждой группе соответствующей политики доступа. Например,
администратор может обратиться к любой среде, включая продакшен, тогда как
доступ разработчика ограничивается средой разработки, а для тестировщика
доступна только тестовая среда.
Рис. 7.1. Структура пользовательских групп
Как показано на диаграмме (рис. 7.1), при присоединении к команде новые поль-
зователи включаются в группу, соответствующую их роли. Таким образом каждый
пользователь получает определенный набор стандартных прав доступа. Права до-
ступа пользовательской группы также могут обновляться, если появляется новая
среда разработки и всем разработчикам необходимо предоставить к ней доступ.
SSO — стандартный процесс, который помогает сократить число дефектов
безопасности и автоматизировать систему. SSO дает возможность пользовате-
лям с учетной записью в другой корпоративной системе использовать единый
идентификатор пользователя и пароль. Механизм FIM (Federated Identity
Management — федеративное управление идентификацией) позволяет поль-
зователям обращаться к системе без пароля через механизм предварительной
аутентификации. Рассмотрим эту возможность более подробно.
FIM и SSO
FIM (федеративное управление идентификацией) предоставляет возможность
подключения системы управления идентификационными данными, когда ин-
формация о пользователе хранится у стороннего поставщика идентификаци-
онных данных (IdP, Identity Provider). При использовании FIM пользователь
предоставляет информацию аутентификации только поставщику IdP, у которого,
в свою очередь, уже имеются доверенные отношения с сервисом.
286 Глава 7. Факторы безопасности
Как показано на рис. 7.2, когда пользователь выполняет вход для обращения
к сервису, поставщик сервиса получает регистрационные данные от IdP, а не
напрямую от пользователя.
Пользователь
Доступ к сервисам
Поставщик сервиса
Аутентификация
Поставщик идентификационных
данных (IdP)
Доверенные
отношения
Рис. 7.2. Процесс аутентификации FIM
SSO позволяет использовать единый набор данных входа, с которым пользова-
тель может обращаться к разным сервисам. В этом случае поставщик сервисов
может указать среду, в которой должен быть выполнен вход, — например, CRM-
система или облачное приложение. Функции IdP может выполнять корпоратив-
ный каталог Active Directory. FIM позволяет использовать аутентификацию по
аналогии с SSO, но без пароля, так как федеративный сервер знает пользователей
и позволяет им обращаться к информации.
Существуют разные способы реализации FIM и SSO. Рассмотрим некоторые
популярные варианты управления идентификационными данными и доступом
(IAM, Identity and Access Management).
Kerberos
Kerberos — протокол аутентификации, который позволяет двум системам без-
опасно идентифицировать друг друга и реализовать SSO. Он работает в модели
«клиент — сервер» и применяет систему тикетов для идентификации пользо-
вателей.
Kerberos использует центр распространения ключей (KDC, Key Distribution
Center), упрощающий аутентификацию между двумя системами. KDC состоит из
двух логических частей — сервера аутентификации (AS, Authentication Server)
и сервера выдачи тикетов (TGS, Ticket-Granting Server).
Выбор технологий для безопасности архитектуры 287
Kerberos хранит секретные ключи для каждого клиента и сервера в хранилище
данных. Между двумя системами создается безопасная сессия на время обме-
на данными, при этом стороны идентифицируются по хранимому секретному
ключу. На рис. 7.3 изображен процесс аутентификации Kerberos.
Рис. 7.3. Аутентификация Kerberos
Как видно из диаграммы, обращение к сервису подразумевает серию шагов.
1. Когда вы обращаетесь к сервису в своей компьютерной сети, ваш компьютер
(клиент) запрашивает тикет у специального сервиса, который называется
сервером аутентификации (AS, Authentication Server).
2. Сервер AS проверяет, присутствуете ли вы в его базе данных. Если ваши
данные найдены, он создает тикет выдачи тикета (TGT, Ticket-Granting
Ticket), а также ключ сессии, и отправляет их вашему компьютеру. Вы
можете разблокировать ключ сессии своим паролем, но разблокировать
TGT не удастся, потому что он заблокирован ключом, имеющимся только
yTGS.
3. Ваш компьютер берет TGT и запрашивает у другого сервера (TGS) тикет
сервиса для обращения к нужному вам сервису.
4. TGS проверяет TGT и при отсутствии проблем возвращает тикет сервиса,
при помощи которого ваш компьютер может доказать сервису, что у него
есть право на обращение к нему.
5. Ваш компьютер предъявляет тикет сервису, и, если сервис соглашается, что
тикет действителен, вы получаете доступ к сервису.
288 Глава 7. Факторы безопасности
Kerberos весьма полезен, но он распространяется с открытым кодом, а боль-
шие организации обычно предпочитают более управляемое ПО с мощной
поддержкой — например, Active Directory. Рассмотрим рабочий механизм
одного из самых популярных инструментов управления пользователями,
Microsoft AD, базирующегося на протоколе LDAP (Lightweight Directory
Access Protocol).
Microsoft Active Directory
AD — идентификационный сервис, разработанный компанией Microsoft для
пользователей и машин. В AD используется контроллер домена, также называе-
мый AD DS (Active Directory Domain Services), на котором хранятся информация
о пользователе, удостоверения доступа и идентификационные данные, а также
системная информация.
На рис. 7.4 представлена простая схема процесса аутентификации.
Устройство
пользователя
1. Пользователь вводит удостоверения доступа.
----------------------------------------►
Active Directory
4------------------------------------------
2. AD проверяет пользовательские удостоверения
и возвращает маркер аутентификации.
------------------------------►
3. Маркер доступа, предоставленный
пользователю для поддержания сессии.
Рис. 7.4. Аутентификация AD
Сервис
Как видно из рис. 7.4, входом пользователя управляет AD в сетях домена. Поль-
зователь сначала отправляет запрос контроллеру домена со своими удостовере-
ниями и взаимодействует с Active Directory Authentication Library (ADAL).
AD AL проверяет удостоверения и возвращает маркер доступа с непрерывной
сессией для запрашиваемого сервиса.
LDAP — стандартный протокол, который работает с древовидной иерархической
структурой информации, хранящейся в каталогах. Active Directory Lightweight
Выбор технологий для безопасности архитектуры 289
Directory Services (AD LDS) предоставляет интерфейс LDAP к каталогу пользо-
вателей и систем. Для шифрования файлов и сетевого трафика Active Directory
Certiicate Services (AD CS) предоставляет функциональность инфраструктуры
ключей. Active Directory Federation Services (AD FS) предоставляет механизм
доступа к внешним ресурсам — например, данным входа веб-приложений для
многих пользователей.
Поскольку многие организации переходят на облачные сервисы, рассмотрим
подробнее сервис каталогов, предоставляемый облачной платформой AWS.
AWS Directory Service
Сервис AWS Directory Service связывает ресурсы AWS из вашей учетной за-
писи с существующими локальными средствами управления пользователями —
такими, как AD. AWS Directory Service создает новый каталог управления
пользователями в облаке AWS, что делает возможным безопасное соединение
с локальным каталогом. После установления соединения все пользователи могут
обращаться к облачным ресурсам и локальным приложениям с существующими
удостоверениями.
AWS AD Connector — еще один сервис, который связывает существующий
экземпляр Microsoft AD с облаком AWS; специальный инструмент синхрониза-
ции каталогов не понадобится. Пользователи с правами администратора могут
управлять ресурсами AWS при помощи AWS IAM.
AD Connector позволяет включить поддержку MS А посредством интеграции
с существующей инфраструктурой MFA — такой, как YubiKey, маркеры Gemalto
или маркеры RSA.
Для небольшой базы (менее 5000 пользователей) AWS предоставляет Simple
AD — управляемый каталог на базе Samba 4 Active Directory Compatible Server.
Simple AD поддерживает такую общую функциональность, как управление
учетными записями пользователей, управление пользовательскими группами,
SSO на базе Kerberos и политики пользовательских групп.
Среди других сервисов каталогов, предоставляемых крупным технологически-
ми компаниями, можно выделить Okta, Centrify, Ping Identity и Oracle Identity
Cloud Service (IDCS).
SAML
Ранее, в подразделе «FIM и SSO», вы узнали о поставщиках IdP и поставщиках
сервисов. Чтобы обратиться к сервису, пользователь проверяется поставщиком
IdP, который, в свою очередь, имеет доверенные отношения с поставщиком
сервиса. Язык разметки SAML (Security Assertion Markup Language) может
использоваться для установления доверенных отношений между IdP и по-
ставщиком сервиса через XML (extensible Markup Language); таким образом
стандартизируется обмен данными между IdP и поставщиком сервиса.
290 Глава 7. Факторы безопасности
Утверждение (assertion) SAML представляет собой документ XML с пользова-
тельской авторизацией, который IdP отправляет поставщику сервиса. На рис. 7.5
представлен процесс передачи утверждений SAML.
Удостоверения, отправленные
для проверки
База данных пользователей
Экран входа
Пользователь
4
5
Отправляет статус проверки
3
Отображение
страницы входа
1
Запрос доступа
к ресурсам
7
Пользователь получает
доступ к ресурсам
Поставщик сервиса
2
Запрос, не прошедший аутентификацию, перенаправляется к SAML IdP в запросе SAML
Поставщик SAML IdP
6
Поставщик SAML IdP отправляет ответ SAML
Рис. 7.5. Аутентификация пользователя с использованием SAML
Как показано на диаграмме, для аутентификации пользователя с использованием
SAML выполняются следующие действия.
1. Пользователь отправляет запрос на обращение к сервису (например, при-
ложению CRM Salesforce).
2. Поставщик сервиса (CRM-система) отправляет поставщику SAML IdP за-
прос SAML с информацией пользователя.
3. SAML IdP вызывает страницу входа SSO, где пользователь вводит данные
для аутентификации.
4. Удостоверение обращения пользователя направляется в базу данных поль-
зователей — хранилище идентификационных данных — для проверки.
В рассматриваемом случае хранилищем идентификационных данных поль-
зователей является AD.
5. Хранилище идентификационных данных пользователей отправляет статус
проверки пользователя поставщику SAML IdP, с которым у хранилища
существуют доверенные отношения.
6. SAML IdP отправляет утверждение SAML поставщику сервиса (приложению
CRM) с информацией о проверке пользователя.
7. После получения ответа SAML поставщик сервиса предоставляет пользова-
телю доступ к приложению.
Выбор технологий для безопасности архитектуры 291
Иногда поставщик сервиса также может выполнять функции IdP. Технология
SAML очень популярна при установлении отношений между любым хранили-
щем идентификационных данных и поставщиком сервиса. Все современные
приложения хранилищ идентификационных данных совместимы с SAML 2.0,
что обеспечивает их бесшовное взаимодействие. SAML позволяет устанавливать
связь с идентификационными данными пользователя и открывает возможность
использования SSO для корпоративных пользователей.
Для больших пользовательских баз (например, в социальных сетях и интернет-
магазинах) протоколы OAuth (сокращение от Open Authorization) и OpenlD
подходят лучше, чем SAML. В следующих разделах более подробно рассматри-
ваются OAuth и OIDC (OpenlD Connect).
OAuth
OAuth — протокол авторизации, который является открытым стандартом
и предоставляет защищенное делегирование доступа приложениям. OAuth не
обменивается данными паролей, но использует маркер авторизации для уста-
новления идентификации между поставщиками сервисов и потребителями.
Пользователи приложения предоставляют доступ к своей информации без
предоставления учетных данных.
Хотя протокол OAuth в основном предназначен для авторизации, многие орга-
низации начали добавлять собственные механизмы аутентификации.
OIDC — протокол, определяющий стандарт аутентификации на базе механизма
авторизации OAuth 2.0. OAuth 2.0 дает основу для авторизации (предоставляя
доступ к ресурсам); OIDC добавляет дополнительный уровень для выполнения
аутентификации пользователя. Это означает, что OIDC не только помогает
приложениям определить, какие ресурсы доступны для пользователя, но и про-
веряет личность пользователя, обращающегося к сервису. Клиенты получают
возможность проверять личность пользователя на основании аутентификации,
выполняемой сервером авторизации, а также получать основную информацию
о пользователе из профиля совместимым способом в стиле REST.
Технологические гиганты — такие, как Amazon, Facebook, Google и X — дают
возможность пользователям предоставлять информацию своих учетных записей
сторонним приложениям. Например, можно войти в приложение для работы
с фотографиями, используя учетные данные Facebook, и разрешить новому при-
ложению обращаться только к фотографиям в Facebook. На рис. 7.6 представлен
процесс делегирования доступа OAuth, где пользователь указывает приложению
LinkedIn получить свое фото профиля из Facebook.
Как показано на диаграмме, процесс аутентификации в этом сценарии проходит
по следующей схеме.
1. Пользователь отправляет запрос к приложению Einkedln на получение фото-
графии для профиля из Facebook.
292 Глава 7. Факторы безопасности
2. Приложение LinkedIn запрашивает авторизацию для обращения к фото-
графиям пользовательского профиля в Facebook.
3. Сервер авторизации (в данном случае учетная запись пользователя в Facebook)
создает и выводит для пользователя экран подтверждения согласия.
4. Пользователь дает согласие на запрос к приложению LinkedIn для обращения
только к фотографиям в его профиле Facebook.
5. После получения одобрения сервер авторизации Facebook отправляет код
авторизации запрашивающему приложению LinkedIn.
6. Приложение LinkedIn запрашивает маркер авторизации от сервера автори-
зации (учетной записи Facebook) с использованием кода авторизации.
7. Сервер авторизации идентифицирует приложение LinkedIn и проверяет
действительность кода авторизации. Если код проходит проверку, сервер
выдает маркер доступа приложению LinkedIn.
8. Приложение LinkedIn теперь может обращаться к таким ресурсам, как фото-
графии из профиля Facebook, с использованием маркера доступа.
Рис. 7.6. Делегирование пользовательского доступа с OAuth 2.0
Примечание. В наше время чаще используется версия OAuth 2.0, которая
работает быстрее OAuth 1.0 и более удобно реализуется.
В следующем разделе рассмотрим JWT (JSON Web Token) — простой и до-
ступный формат маркера, который может использоваться с OAuth и пользуется
популярностью с OpenlD.
Выбор технологий для безопасности архитектуры 293
JWT
JWT — компактный и автономный механизм безопасной передачи информации
между сторонами в виде объекта JSON. Эту информацию можно проверить,
и ей можно доверять, потому что она снабжается цифровой подписью. Маркеры
JWT могут подписываться с использованием секрета или пары из открытого/
закрытого ключа.
JWT имеет структуру J SON с информацией о времени прекращения действия,
источнике, теме и т. д. Он надежнее SWT (Simple Web Token) и проще SAML 2.0.
Структура JWT представлена на рис. 7.7.
Encoded IWIIAtMtHMM
eyJhbGciOiJIUzIl NUsInR5cCI6IkpXVCJ9 .ey
JzdWI101IxOTE5M]AyMClElm5hbWU10iJTb2x1d
GlvbiBSCinNoaXRlY3Qg£0FL2GJvb2slLCJpYXQi
Oj IxM jExHDEwHXe. kj V743Dko6XciP3Kp3Vr rRc
WSJvBXzK3JkHWqGKhIE
Decoded « ммпмсжвжжг
Рис. 7.7. Пример JWT
На скриншоте вы видите маркер JWT из трех частей, разделенных точками. Пер-
вая часть (заголовок) указывает на тип маркера (J WT) и алгоритм, используемый
для цифровой подписи (например, HS256 или RSA). Вторая часть (полезная
нагрузка) содержит утверждения — блоки информации о пользователе и другие
данные. Последняя часть содержит цифровую подпись, которая гарантирует,
что маркер не был изменен, и подтверждает отправителя J WT.
JSON имеет более простую структуру, чем XML, и занимает меньше места,
вследствие чего JWT компактнее SAML. JWT — отличный вариант для пере-
дачи информации в средах HTML и HTTP. Ввиду своей компактности маркеры
JWT идеально подходят для передачи идентификационных данных проверен-
ных пользователей между сервисами в микросервисной архитектуре или для
предоставления маркеров доступа, позволяющих пользователям обращаться
к ресурсам. Они используются в различных сценариях аутентификации и ав-
торизации, особенно в мобильных и веб-приложениях.
294 Глава 7. Факторы безопасности
В этом разделе вы познакомились с самыми распространенными инструментами
и сервисами управления пользователями. Тем не менее существуют и другие
протоколы и сервисы для аутентификации и авторизации пользователей.
Реализация перечисленных выше протоколов может быть достаточно сложной.
Существует целый ряд готовых программных продуктов, упрощающих эту
работу.
Amazon Cognito — сервис управления пользователями, предоставляемый AWS.
Он включает авторизацию на базе таких стандартов, как SAML 2.0, OIDC
и OAuth 2.0, в сочетании с корпоративным каталогом пользователей, способ-
ным взаимодействовать с AD. Okta и Ping Identity предоставляют средства
корпоративного управления пользователями и возможность взаимодействия
с различными инструментами поставщиков сервисов в одном месте.
Если ваше приложение имеет выход в интернет, всегда следует учитывать риск
различных атак. Рассмотрим некоторые распространенные виды атак и органи-
зацию первого уровня защиты веб-приложения.
Веб-безопасность
Современным пользователям нужно, чтобы сервисы были доступны в режиме
24/7. Бизнес развивается для работы в онлайне, а для этого ему приходится адап-
тировать модели веб-приложений. Веб-приложения также помогают компаниям
получить доступ к глобальной клиентской базе. Такие сервисы, как интернет-
банкинг и интернет-магазины, всегда доступны и работают с чувствительными
клиентскими данными (например, платежными реквизитами и идентификаци-
онными данными плательщика).
В наше время веб-приложения занимают центральное место в любом бизнесе
и открыты для окружающего мира. Веб-приложения могут иметь уязвимости,
открывающие их для кибератак и взлома. Рассмотрим некоторые распростра-
ненные типы кибератак и способы борьбы с ними.
Кибератаки
Веб-приложения уязвимы для взлома. Хакеры устраивают кибератаки из разных
мест и разными способами. Подобно тому как вы запираете и защищаете фи-
зическое здание, веб-приложение также должно быть защищено от незаконной
активности. Рассмотрим некоторые стандартные методы атаки, которые могут
создать уязвимости безопасности в веб-приложениях.
DoS- и DDoS-атаки
Атаки отказа в обслуживании, или DoS-атаки (Denial of Service), направлены
на то, чтобы сделать сайт недоступным для пользователей. Для проведения
успешной DoS-атаки злоумышленник применяет различные технологии, по-
требляющие сетевые и системные ресурсы, тем самым блокируя доступ для
Выбор технологий для безопасности архитектуры 295
легитимных пользователей приложения. Атакующий использует множество
хостов для координации атаки против одной цели.
Распределенные атаки отказа в обслуживании, или DDoS-атаки (Distributed
Denial of Service), используют множество захваченных систем, часто зараженных
вредоносными программами, для перегрузки одной целевой системы запросами.
Целевая система (объект атаки) не справляется с потоком запросов, что приво-
дит к прерыванию обслуживания. Злоумышленник дистанционно управляет
взломанными системами для проведения атаки.
Как показано на рис. 7.8, DDoS-атака происходит при истощении емкости ре-
сурсов целевой системы запросами от многих систем.
Рис. 7.8. DDoS -атака
Общий принцип DDoS-атаки заключается в привлечении дополнительных
хостов для усиления потока запросов, отправляемых к цели, в результате чего
та перегружается и становится недоступной. DDoS-атаки часто проводятся
силами множества захваченных систем, когда ботнет создает переполнение
трафика в атакуемой системе.
Ботнет представляет собой сеть устройств, зараженных вредоносными
программами и управляемыми через них.
Самая распространенная DDoS-атака организуется на уровне приложения с при-
менением либо DNS-флуда, либо атаки на согласование SSL (SSL negotiation
296 Глава 7. Факторы безопасности
attack). При DNS-флуде1 атакующие истощают ресурсы сервера DNS чрезмер-
ным количеством запросов. В ходе атаки на согласование SSL атакующие отправ-
ляют большой объем нечитаемых данных для дешифрования SSL, требующего
значительных вычислительных ресурсов. Злоумышленник может выполнять
другие атаки на базе SSL на парки серверов и перегружать их выполнением
бессмысленных операций.
На уровне инфраструктуры типичная DDoS-атака выполняется по следующим
схемам:
• отражение UDP (User Datagram Protocol): при отражении UDP атакующий
фальсифицирует IP-адрес целевого сервера и выдает запрос, который воз-
вращает большой объем ответов от взломанного сервера-«отражателя»;
• SYN-флуд: атакующие блокируют работу сервиса TCP (Transmission Control
Protocol) целевого сервера, создавая и оставляя большое количество подклю-
чений, не позволяя легитимным пользователям получить доступ к серверу.
Часто атакующие пытаются похитить конфиденциальные данные клиентов. Для
этого они используют различные виды атак, называемые атаками внедрения
SQL, или SQL-инъекцией (SQLi, SQL injection). В следующем разделе этот
класс атак рассматривается более подробно.
Атаки SQLi
Как следует из названия, атакующие внедряют вредоносный код SQL для получе-
ния контроля над базой данных SQL и чувствительными данными пользователя.
Атакующий использует SQLi для получения несанкционированного доступа
к информации, контроля над приложением, создания новых пользователей и т. д.
Для примера возьмем приложение для обработки заявок на кредиты. В базе
данных присутствует поле load Id, которое используется клиентами для полу-
чения всей информации, относящейся к их кредиту. Если не принять должных
мер защиты, атакующий может выполнить запрос вида SELECT * FROM loans
WHERE loanld = 117 or " 1=1" и получить доступ ко всей базе данных клиентов,
так как условие всегда будет истинным.
Также часто встречается другой способ взлома пользовательских данных с ис-
пользованием внедрения скриптов — межсайтовые скриптовые атаки (XSS),
при которых злоумышленник выдает себя за легитимного пользователя. В сле-
дующем разделе они рассматриваются более подробно.
XSS-атаки
Наверняка вам попадались фишинговые сообщения со ссылками, ведущими на
копии известных сайтов. Переход по такой ссылке может привести к нарушению
защиты данных посредством XSS. В этой разновидности атак злоумышленник
1 Флуд от англ, flood — наводнение. — Примеч. пер.
Выбор технологий для безопасности архитектуры 297
встраивает вредоносный код в настоящий сайт. Этот код выполняется, когда
ничего не подозревающий пользователь посещает веб-страницу.
Атакующий может внедрять код разными способами — например, встраивая его
непосредственно в строку URL или вставляя фрагмент кода JavaScript в веб-
страницу. При загрузке веб-страницы клиентский код JavaScript выполняется
и похищает cookie браузера.
Часто cookie содержат конфиденциальную информацию — например, маркер
доступа и аутентификацию банковских сайтов или интернет-магазинов. Ис-
пользуя похищенные cookie, злоумышленник может получить доступ к вашему
банковскому счету и похитить ваши честно заработанные деньги.
CSRF-атаки
Атаки межсайтовой подделки запросов (CSRF, Cross-Site Request Forgery)
пользуются идентификационными данными пользователей, создавая пута-
ницу и заставляя аутентифицированных пользователей выполнять операции
с изменением состояния — например, менять пароль от интернет-магазина или
отправлять запрос на перевод денег.
Эти атаки несколько отличаются от XSS-атак тем, что в CSRF-атаках злоумыш-
ленник пытается фальсифицировать запрос вместо вставки скриптового кода.
Например, он может сформировать запрос на перевод определенной суммы денег
из банка пользователя и отправить тому соответствующую ссылку в сообще-
нии электронной почты. Когда пользователь щелкает ссылку, банк получает
запрос и переводит деньги на учетную запись атакующего. CSRF-атаки могут
быть особенно разрушительными, если атакующий получает доступ к учетной
записи администратора.
Переполнение буфера и атаки повреждения памяти
Для ускорения обработки программа записывает данные во временную об-
ласть памяти, называемую буфером. В атаках переполнения буфера злоумыш-
ленник может переписать часть памяти, прилегающую к буферу, намеренно
вызывая переполнение буфера и обращаясь к смежной памяти, где может
храниться исполняемый код приложения. Злоумышленник может заменить
исполняемый код своей программой и взять под контроль всю систему. Если
рассматривать приложение в целом, другие угрозы безопасности существуют
на уровне инфраструктуры, уровне сети и уровне данных. Рассмотрим неко-
торые стандартные способы подавления и предотвращения рисков безопас-
ности на веб-уровне.
Снижение рисков и повышение веб-безопасности
Безопасность должна обеспечиваться на каждом уровне приложения, при-
чем веб-уровень требует особого внимания из-за его связи с внешним миром.
Необходимые шаги для защиты этого уровня включают установку новейших
298 Глава 7. Факторы безопасности
исправлений безопасности, соблюдение лучших практик разработки и обеспе-
чение правильного выполнения аутентификации и авторизации.
Существуют различные методы защиты веб-приложений; рассмотрим два самых
распространенных из них.
WAF
WAF (Web Application Firewall) — файрволы, применяющие конкретные
правила к трафику HTTP и HTTPS (то есть портам 80 и 443). WAF анали-
зируют веб-трафик и проверяют, что он соответствует нормам предпола-
гаемого поведения. Они предоставляют дополнительный уровень защиты
от веб-атак.
Ограничение WAF — способность анализировать объем или тип запросов,
передаваемых сервису, и определять порог допустимых запросов для каждого
пользователя, сессии или IP-адреса. Белые и черные списки позволяют допускать
или блокировать пользователей явно.
AWS WAF — один из примеров WAF, который добавляет безопасность на
веб-уровне за счет создания и применения правил фильтрации веб-трафика.
В основе этих правил лежат условия, включающие заголовки HTTP, геолокацию
пользователей, вредоносные IP-адреса, настраиваемые URI (Uniform Resource
Identifiers) и т. д. Правила AWS WAF блокируют типичные веб-атаки — такие,
как XSS и SQLi. Вы можете создать единый набор правил для среды, в которой
работают разные веб-сайты и веб-приложения, и повторно использовать правила
в разных приложениях, чтобы не создавать их заново.
В целом WAF представляет собой инструмент, применяющий набор опреде-
ленных правил к трафику HTTP. Он фильтрует веб-запросы на основании
таких данных, как IP-адреса, заголовки HTTP, тела HTTP и строки URI. WAF
может блокировать DDoS-атаки, отклоняя нелегитимный трафик. Рассмотрим
блокировку DDoS более подробно.
Блокировка DDoS-атак
Устойчивые архитектуры способны предотвращать или подавлять DDoS-атаки.
Фундаментальный принцип обеспечения безопасности архитектуры — сокра-
щение количества потенциальных целей, которые может поразить атакующий.
Проще говоря, если экземпляр не обязательно делать открытым, то его не нужно
делать открытым.
Существуют разные стратегии минимизации поверхности атаки.
• Там, где возможно, сокращайте количество точек входа в интернет — на-
пример, откройте входящий доступ балансировщику нагрузки, но не веб-
серверам.
• Выявите и устраните все необязательные точки входа в интернет. Например,
можно создать файловое хранилище для отправки данных поставщиками, но
Выбор технологий для безопасности архитектуры 299
ограничить к нему доступ, чтобы он был только у небольшой группы, а не
у всего глобального интернет-трафика.
• Скройте все необходимые точки входа в интернет от ненадежных конечных
пользователей, чтобы они не могли к ним обращаться.
• Изолируйте точку доступа и примените особую политику ограничений для
трафика конечных пользователей (в отличие от трафика управления при-
ложением).
• Создайте изолированную точку входа в интернет для минимизации поверх-
ности атаки.
Вашей главной целью должна быть блокировка DDoS-атак на границе CDN.
Бороться с DDoS-атаками, которые доберутся до серверов приложений, будет
сложнее и затратнее. На рис. 7.9 изображен пример блокировки DDoS для ра-
бочей нагрузки в облаке AWS.
Рис. 7.9. Стратегия трехслойной блокировки DDoS с использованием WAF
На диаграмме изображена трехслойная архитектура, в которой WAF размещается
между двумя балансировщиками нагрузки для блокировки DDoS-атак.
Многие DDoS-атаки строятся на таких стратегиях, как SYN-флуд и отражение
UDP. Amazon CloudFront предотвращает их, принимая только четко оформлен-
ные подключения еще до того, как атакующий сможет добраться до серверов
приложений. Некоторые CDN (такие, как Amazon CloudFront) помогают спра-
виться с DDoS-атаками за счет того, что трафик изолируется в географически
обособленной области и не может влиять на другие области. Сетевые файрволы
помогают управлять входящим и исходящим трафиком на уровне отдельных
серверов.
Как упоминалось в предыдущем разделе, WAF используются для защиты веб-
приложений от таких атак, как XSS и SQLi. Кроме того, WAF помогают обна-
руживать и предотвращать DDoS-атаки на уровне веб-приложения.
300 Глава 7. Факторы безопасности
Чтобы заблокировать D Do S-атаку, следует применить либо горизонтальное,
либо вертикальное масштабирование. Схема масштабирования может выглядеть
примерно так.
1. Начните с выбора подходящего размера сервера и конфигурации веб-
приложения.
2. Используйте балансировщик нагрузки для распределения трафика по парку
серверов и добавьте автомасштабирование для добавления/удаления серверов
по мере надобности.
3. Наконец, используйте CDN и сервер DNS, поскольку они созданы для об-
работки масштабируемого трафика.
Масштабирование для DDoS-атак — отличный пример того, почему так важно
выделить разумное максимальное количество серверов. DDoS-атака может
масштабировать серверы до количества, которое будет стоить чрезвычайно
дорого, но при этом не гарантирует доступности. Установление разумных
максимальных пределов для предполагаемых обычных выбросов трафика по
крайней мере не позволит DDoS-атаке нанести слишком большой финансовый
ущерб организации.
В этом разделе вы узнали о рисках безопасности и уязвимостях веб-уровня,
а также о стандартных способах их предотвращения. Рассмотрим теперь более
подробно защиту уровня инфраструктуры.
Защита приложения и его инфраструктуры
В предыдущем разделе вы узнали о защите веб-уровня. Так как безопасность
должна применяться на каждом уровне рабочей нагрузки, обратимся к теме
защиты уровней приложения и сети архитектуры.
Усиление защиты приложения и операционной системы
Полностью избежать уязвимостей в приложении невозможно, но можно мини-
мизировать риски атак за счет методов усиления защиты (hardening) операцион-
ной системы, файловой системы и каталога приложения. Если злоумышленник
получит доступ к приложению, он сможет завладеть и правами пользователя
root, чтобы организовать атаку на всю инфраструктуру.
Важно ограничить атаки на уровне приложения, задавразрешения для каталога.
На уровне процесса ограничьте максимальную загрузку памяти и процессора
для предотвращения DoS-атак.
Задайте подходящие разрешения на уровне файлов, папок и разделов. Не предо-
ставляйте права root приложению или его пользователям. Создайте отдельный
каталог для каждого приложения и предоставляйте доступ только тем пользо-
вателям, которым это явно разрешено. Общий доступ должен предоставляться
только к некоторым приложениям.
Выбор технологий для безопасности архитектуры 301
Автоматизируйте перезапуск приложения с помощью таких инструментов,
как DAEMON Tools и Supervisord. Избегайте ручных решений, для которых
пользователям требуется выполнить вход на сервер. В операционных системах
Linux запуск/остановка приложения могут осуществляться с помощью таких
инструментов, как systemd, или скриптов System V init.
Снижение уязвимости программного обеспечения и безопасный код
Всегда рекомендуется применять последние патчи безопасности, выпущенные
поставщиком операционной системы. Это восполняет пробелы в безопасности
системы и помогает защитить систему от уязвимостей, позволяющих злоумыш-
ленникам похитить сертификат безопасности или выполнить произвольный код.
Регулярное обновление системы новейшими патчами безопасности очень важно.
Лучше автоматизировать процесс их установки сразу же после их появления.
Тем не менее установка патча иногда может нарушить работу выполняемого
приложения, поэтому полезно создать пайплайн непрерывной интеграции и не-
прерывного развертывания (CI/CD) с автоматизированным тестированием
и развертыванием. Процесс CI/CD более подробно рассматривается в главе 11
«DevOps и фреймворк архитектуры решений».
Облачная платформа AWS предоставляет системный менеджер — программу,
которая позволяет применять патчи безопасности и мониторить парк серверов
в облаке. Для автоматизации установки исправлений безопасности можно вос-
пользоваться автоматическими обновлениями. Выбирая управляемые сервисы
от провайдеров облачных платформ, вы, по сути, освобождаетесь от бремени
управления инфраструктурой. Провайдер берет на себя настройку, управление,
эксплуатацию и оптимизацию сервисов, в том числе стандартные задачи под-
держки — в частности, установку патчей, чрезвычайно важную для безопасности
и производительности.
Не забудьте интегрировать в процесс разработки лучшие практики безопасного
программирования, как рекомендует проект OWASP (Open Web Application
Security Project). Подробную информацию о проекте можно найти по адресу
owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-
introduction/05-introduction.
Сетевая безопасность
Когда речь заходит о защите инфраструктуры, прежде всего следует позаботить-
ся о защите сети. Физическая безопасность ИТ-инфраструктуры в дата-центре
должна обеспечиваться его провайдерами. А ваша обязанность как владельца
приложения — думать о безопасности сети.
Пример с провайдером публичной облачной платформы — такой, как AWS — по-
может лучше понять, как обеспечивается сетевая безопасность. Этот же пример
можно применить в локальной или частной облачной сетевой инфраструктуре.
302 Глава 7. Факторы безопасности
Как показано на рис. 7.10, о безопасности следует заботиться на каждом уровне,
и на каждом уровне должны быть определены границы доверия с минимальным
доступом.
^3 06jiaKoAWS ZSX Шлюз Интернета
Рис. 7.10. Сетевая конфигурация для безопасности инфраструктуры
На этой диаграмме балансировщик нагрузки находится в открытой подсети,
которая может принимать интернет-трафик и распределять его по парку сер-
веров приложений. Фильтрация трафика WAF основана на заданных правилах
и защищает приложение от различных атак, как вы узнали в предыдущем раз-
деле. Парк серверов приложений и серверы базы данных находятся в частных
подсетях, это означает, что прямой доступ к ним из интернета невозможен.
Рассмотрим эту архитектурную диаграмму подробнее, уровень за уровнем.
• Amazon VPC (Virtual Private Cloud ) предоставляет логически изолированную
сеть для облачной инфраструктуры. VPC становится персонализированной
сетевой средой в облаке и используется для размещения ресурсов. VPC
позволяет разделять разные среды и ресурсы. Можно создать несколько
Выбор технологий для безопасности архитектуры 303
VPC в каждой учетной записи AWS или регионе. При создании VPC опре-
деляется диапазон IP-адресов с помощью записи CIDR (Classless Inter-
Domain Routing). Эта запись позволяет компактно представлять диапазоны
IP-адресов. Например, блок CIDR 10.0.0.0/16 охватывает все IP-адреса от
10.0.0.0 до 10.0.255.255. Диапазон включает 65 535 IP-адресов, доступных
для использования.
• Подсети представляют собой части сети, разделенной с использованием
диапазонов CIDE, которые устанавливают безопасные границы между част-
ными и публичными ресурсами. Вместо того чтобы упорядочивать подсети
по приложению или функции (например, веб-уровень, уровень приложения
или уровень данных), эффективнее организовать их в зависимости от доступа
к интернету. Такая конфигурация обеспечивает четкую изоляцию на уровне
подсетей и позволяет различать общие и частные (внутренние) ресурсы.
• В этой конфигурации ресурсы, которым необходим доступ к интернету (на-
пример, балансировщики нагрузки, экземпляры NAT и хосты-бастионы),
размещаются в открытой подсети. Другие ресурсы (такие, как базы данных
и приложения) размещаются в частной подсети. Так создается четкое
разделение между уровнями ресурсов, причем экземплярам приложения
и ресурсам данных выделяются собственные частные подсети. В AWS
большинство ресурсов может размещаться в частных подсетях, а откры-
тые подсети используются только там, где требуется доступ к интернету.
Рекомендуется выделять для частных подсетей больше IP-адресов, чем
для открытых подсетей, чтобы обеспечить достаточное пространство для
большинства ресурсов, которые будут находиться в частных сетях. Подсети
обеспечивают базовое разделение между ресурсами с правилами NACL
(Network Access Control List), но группы безопасности предоставляют
более детализированный уровень управления трафиком. Такой подход
предотвращает чрезмерное усложнение инфраструктуры и неэффективное
использование IP-адресов.
• Таблица маршрутизации состоит из правил, называемых маршрутами
(routes), которые определяют, какие серверы приложений получают сетевой
трафик. Для улучшения безопасности рекомендуется использовать отдельную
таблицу маршрутизации для каждой подсети.
• Группы безопасности действуют как виртуальные файрволы, которые
управляют входящим и исходящим трафиком для одного или нескольких
экземпляров. Эти экземпляры могут задаваться в диапазоне CIDR или ча-
стью другой назначенной группы безопасности. В соответствии с принципом
наименьших привилегий группы безопасности настраиваются на отклонение
всего входящего трафика по умолчанию. После этого можно установить кон-
кретные правила фильтрации трафика на основании таких протоколов, как
TCP, UDP и ICMP (Internet Control Message Protocol). Такая конфигурация
гарантирует, что только необходимый и авторизованный трафик сможет об-
ращаться к экземплярам, а это повышает безопасность сети.
304 Глава 7. Факторы безопасности
• NACL — необязательный уровень безопасности в форме виртуального файр-
вола, контролирующего как входящий, так и исходящий трафик на уровне
подсети. В отличие от группы безопасности, имеющей состояние, NACL
работает без сохранения состояния. Отсутствие состояния означает, что
каждый запрос, входящий или исходящий, рассматривается независимо. На-
пример, даже если входящий запрос допустим, соответствующий исходящий
ответ также должен быть явно разрешен по правилам NACL. Это требует
тщательного определения правил как для входящего, так и для исходящего
трафика, чтобы обеспечить правильное прохождение трафика и безопасность
на уровне подсети.
• Интернет-трафик маршрутизируется через интернет-шлюз (IGW), чтобы
подсеть была открытой. По умолчанию доступ к интернету для интернет-тра-
фика в среде запрещен. Шлюз должен быть присоединен к VPC, а в таблице
маршрутизации подсети должны быть определены правила для IGW.
• Частная подсеть блокирует весь входящий и исходящий интернет-трафик,
но исходящий трафик может потребоваться серверам для установки про-
грамм и патчей безопасности. Шлюз NAT позволяет экземплярам в частной
подсети инициировать исходящий трафик в интернет и защищает ресурсы
от входящего интернет-трафика.
• Хост-бастион работает как промежуточный сервер, предоставляющий доступ
к другим ресурсам частной подсети. Для хоста-бастиона необходимо обес-
печить более жесткие меры безопасности, чтобы к нему могли обращаться
только те, кому это разрешено. При входе на сервер для аутентификации
всегда используется шифрование с открытым ключом вместо обычного метода
с идентификатором пользователя и паролем.
Организации собирают, хранят и анализируют журнальные данные по мно-
гим причинам. В частности, чтобы диагностировать сбои соединения, решать
проблемы безопасности и оценивать политики сетевого доступа. Вы должны
отслеживать поток трафика в системную сеть VPC, для чего необходимо сохра-
нять информацию о входящем и исходящем трафике из сети. Журналы потока
трафика VPC позволяют получить эту информацию вместе с информацией
о принятом и отклоненном трафике для заданного ресурса, что помогает лучше
понять закономерности трафика.
Журналы потока трафика служат инструментом безопасности для мониторинга
трафика к экземплярам. Можно настраивать сигналы для конкретных типов тра-
фика и создавать метрики для выявления трендов и закономерностей. Журналы
потока трафика можно вести для VPC, подсети или сетевого интерфейса. При
создании для подсети или VPC они отслеживают каждый сетевой интерфейс
в этой подсети или VPC. Представим, что у вас имеется VPC с несколькими
подсетями. Создавая журнал потока трафика для сети VPC, можно отслеживать
весь входящий и исходящий трафик через ее сетевые интерфейсы. При обнару-
жении аномальных закономерностей трафика (например, неожиданных пиков
Выбор технологий для безопасности архитектуры 305
в запросах данных с неизвестного IP-адреса) можно настроить оповещение. Такой
активный мониторинг помогает выявить потенциальные угрозы безопасности
или неэффективную работу сети на ранней стадии.
Как видите, на сетевом уровне доступны разные уровни безопасности, которые
помогают защитить инфраструктуру. Хранение ресурсов в изолированной
подсети помогает сократить радиус поражения. Даже если атакующий сможет
проникнуть в один компонент, должна быть возможность изолировать его огра-
ниченным кругом ресурсов. Используйте IDS и IPS перед инфраструктурой
для обнаружения и предотвращения любого вредоносного трафика. Эта тема
рассматривается в следующем разделе.
Системы обнаружения и предотвращения вторжений
Системы обнаружения вторжений (IDS) обнаруживают кибератаки, выпол-
няемые через сетевой трафик, посредством анализа шаблонов атак. Системы
предотвращения вторжений (IPS) идут еще дальше и стараются проактивно
остановить вредоносный трафик.
IPS предоставляет критический анализ потенциальных угроз, расположенных
за файрволом. Система IPS обнаруживает опасный контент (например, вредо-
носные пакеты) и блокирует трафик либо сбрасывает подключения. У IPS есть
два основных метода обнаружения:
• обнаружение на основе сигнатур: метод использует растущую базу данных
уникальных шаблонов (сигнатур), связанных со всеми известными видами
атак;
• обнаружение на основе статистических аномалий: метод устанавливает
эталон нормальной производительности сети и сравнивает с ним случайные
выборки сетевого трафика. При обнаружении значительных отклонений IPS
вмешивается в ситуацию.
Вам нужно будет определить пригодность системы IDS/IPS для требований
приложения. Системы IDS делятся на две категории: серверные и сетевые.
Система обнаружения на основе хоста (HIDS)
Система обнаружения на основе хоста (HIDS, host-based IDS) работает на
каждом хосте среды. Она может анализировать активность на хосте, чтобы
определить, произошла ли атака и успешно ли она завершилась. Для этого она
отслеживает файловую систему, сетевые подключения к хосту и т. д. Программа
(или агент) затем передает центральному/командному приложению информа-
цию о работоспособности или безопасности хоста, за которым она наблюдает.
Преимущества HIDS: она может глубоко анализировать активность на каждом
хосте, может масштабироваться горизонтально по мере надобности (каждому
хосту соответствует свой агент) и не влияет на производительность работаю-
щих приложений. К недостаткам можно отнести дополнительные затраты
306 Глава 7. Факторы безопасности
на управление конфигурацией, которые могут появиться при управлении
агентами на многих серверах, что создает неудобства для некоторых орга-
низаций.
Так как каждый агент работает в изоляции, это усложняет обнаружение скоор-
динированных атак. В таких ситуациях система должна немедленно реагиро-
вать по всем хостам, что требует решения на основе хоста для взаимодействия
с другими компонентами — например, операционной системой и интерфейсом
приложения, развернутого на хосте.
Система обнаружения на основе сети (NIDS)
В случае системы обнаружения на основе сети (NIDS, network-based IDS) в раз-
рыв сети подключается устройство, через которое проходит весь трафик для
проверки на наличие атак.
Очевидное преимущество такого решения — простой/единственный компонент,
развертывание и управление которым осуществляется отдельно от хостов при-
ложения. Устройство усиленно защищено или мониторится способом, который
было бы затруднительно воспроизводить на всех хостах. Единая точка мони-
торинга позволяет анализировать общую картину безопасности и выявлять
аномалии/атаки в одном месте.
Однако NIDS приводит к потери производительности из-за появления допол-
нительного сетевого перехода в приложениях. Необходимость дешифрования/
повторного шифрования трафика для анализа снижает производительность
и создает уязвимость, из-за которой сетевой компонент становится заманчивой
целью для атак. Любой трафик, который IDS не может дешифровать, не может
использоваться для анализа/обнаружения чего-либо.
IDS — инструмент обнаружения и мониторинга, который не работает сам
по себе. IPS обнаруживает, принимает и отклоняет трафик на основании
заданных правил. Решения IDS/IPS помогают предотвращать DDoS-атаки
благодаря своему умению обнаруживать аномалии, которое позволяет им по-
нять, когда нормальные протоколы используются как носитель атаки. Работа
IDS и IPS основана на анализе сетевых пакетов и сравнении их содержимо-
го с базой данных известных угроз. Этот процесс позволяет им выявлять
и реагировать на потенциальные риски безопасности. Непрерывный аудит
и сканирование необходимы, чтобы активно защищать инфраструктуру от
любых атак.
В этом разделе вы узнали, как защитить инфраструктуру от различных атак.
Целью этих атак является захват данных. Необходимо защищать данные
так, чтобы атакующий не мог получить конфиденциальную информацию даже
после их захвата. В следующем разделе рассматривается защита данных с при-
менением средств безопасности на уровне данных, шифрования и резервного
копирования.
Выбор технологий для безопасности архитектуры 307
Безопасность данных
В современном цифровом мире в центре любой системы находятся данные.
Иногда эти данные могут содержать чувствительную информацию: медицин-
ские карты клиентов, платежную информацию, удостоверения личности и т. д.
Очень важно защитить клиентские данные, чтобы предотвратить любой не-
санкционированный доступ к ним. Многие отрасли уделяют особое внимание
защите данных и безопасности.
Прежде чем проектировать решение, следует определить основные практики
безопасности, сочетающиеся с поставленной целью (например, соответствие
нормативным требованиям).
Для защиты данных применяются разные методы. Они будут рассмотрены
в следующих разделах.
Классификация данных
Одна из лучших практик — классификация данных, предоставляющая возмож-
ность разделения данных на категории и обработки упорядоченных данных на
основании уровней безопасности.
В зависимости от чувствительности данных можно планировать требования
к защите данных, их шифрованию и обращению к данным.
Определяя классификацию данных в соответствии с требованиями к рабочей
нагрузке системы, можно создавать средства управления данными и необходи-
мый уровень доступа. Например, такой контент, как пользовательские оценки
и отзывы, часто считается публичным, и открытый доступ к нему вполне до-
пустим, но информация кредитной карты пользователя — строго конфиденци-
альные данные, которые необходимо шифровать и доступ к которым должен
быть максимально ограничен.
На высоком уровне данные можно разделить на следующие категории.
• Конфиденциальные данные (restricted) содержат информацию, которая
может нанести прямой ущерб клиенту при попадании в чужие руки. Не-
корректная работа с такими данными может повредить репутации компании
и отрицательно повлиять на бизнес. К конфиденциальным данным могут
относиться персональные данные клиентов (PH): номера социального
страхования, паспортные данные, номера кредитных карт, платежная
информация.
• Приватные данные (private) содержат чувствительную информацию, которой
может воспользоваться злоумышленник для похищения конфиденциальных
данных. Приватные данные могут включать адреса электронной почты кли-
ентов, номера телефонов, полные имена и адреса.
• Публичные данные (public) открыты и доступны всем и поэтому тре-
буют минимальной защиты — например, оценки и отзывы клиентов,
308 Глава 7. Факторы безопасности
местонахождение клиента, ник пользователя, если пользователь решил
сделать его открытым.
Возможны и более мелкие категории в зависимости от отрасли и характера
пользовательских данных. Классификация данных должна выдерживать баланс
между удобством использования данных и контролем доступа к ним. Настройка
разных уровней доступа, как упоминалось ранее, помогает ограничивать доступ
только к необходимым данным и гарантировать защиту конфиденциальной ин-
формации. Никогда не предоставляйте пользователям прямой доступ к данным;
используйте инструменты, которые могут формировать отчеты в режиме «только
для чтения». Тем самым вы ограничите возможность несанкционированного
доступа к данным.
Шифрование данных в покое
Данные в покое (data at rest) — это данные, которые находятся в постоянном
хранилище, не передаются и не используются: например, в сети хранения дан-
ных (SAN, storage area network), на сетевом накопителе (NAS, network-attached
storage) или в облачном хранилище. Вся конфиденциальная информация должна
быть защищена применением симметричного или асимметричного шифрования
с надежным управлением ключами.
Кроме шифрования, существуют и другие методы защиты данных в покое (такие,
как маскировка и токенизация). Эти методы предоставляют дополнительные
уровни безопасности и особенно полезны в сценариях, когда необходимо ис-
пользовать или передавать конфиденциальную информацию без раскрытия
самих данных.
Шифрование данных — способ защиты, при котором данные из простого текста
преобразуются в закодированный формат шифротекста при помощи ключа
шифрования. Чтобы шифротекст можно было прочитать, его необходимо рас-
шифровать с ключом дешифрования, а ключ дешифрования доступен только
авторизованным пользователям.
Часто используемые методы шифрования на базе ключей относятся к одной из
двух криптографических категорий.
• Шифрование с симметричным ключом: в симметричных алгоритмах один
и тот же ключ используется для шифрования и дешифрования данных.
Каждый пакет данных шифруется с секретным ключом при сохранении
и дешифруется при чтении. Раньше симметричное шифрование применялось
в соответствии со стандартом DES (Data Encryption Standard), в котором
используется 56-разрядный ключ. Сейчас для симметричного шифрования
используется более надежный стандарт AES (Advanced Encryption Standard)
со 128-, 192- или 256-разрядным ключом.
• Шифрование с асимметричным ключом: в асимметричных алгоритмах
задействованы два разных ключа: один используется для шифрования,
Выбор технологий для безопасности архитектуры 309
а другой — для дешифрования данных. В большинстве случаев для шифрова-
ния используется открытый ключ, а для дешифрования — закрытый. Шифро-
вание с асимметричным ключом также известно под названием «шифрование
с открытым ключом». Открытый и закрытый ключи неидентичны, но они об-
разуют пару. Закрытый ключ доступен только для одного пользователя, тогда
как открытый ключ может распространяться между несколькими ресурсами.
Только пользователь, владеющий закрытым ключом, сможет дешифровать
данные. RSA (аббревиатура от фамилий Rivest — Shamir — Adleman) — один
из первых и самых популярных алгоритмов шифрования с открытым ключом,
используемых для безопасной передачи данных по сети.
Шифрование и дешифрование данных отражаются на производительности, так
как они добавляют дополнительный уровень обработки. При выборе данных для
шифрования необходимо тщательно взвесить все плюсы и минусы. Возможно,
для сокращения потерь производительности и управления ключами лучше при-
менять шифрование только там, где это действительно необходимо.
Если зашифровать данные с 256-разрядным ключом безопасности AES, то взло-
мать шифр будет практически невозможно. Расшифровать такие данные можно
только при наличии ключа шифрования, следовательно, он должен храниться
в надежном месте. Рассмотрим основные способы управления, обеспечивающие
защиту ключа шифрования.
Управление ключами шифрования
Управление ключами исключительно важно для эффективного шифрования.
Оно гарантирует, что обращаться к ключам шифрования и работать с ними
смогут только авторизованные пользователи. Эти операции включают создание,
хранение, ротацию и удаление ключей наряду с управлением разрешениями на
доступ к ним. Envelope encryption (конвертное шифрование) — специальный
метод управления ключами, используемый при симметричном шифровании,
когда ключ данных шифрует обычный текст, а главный ключ шифрует ключ
данных. Этот метод повышает безопасность, требуя двух ключей для шифро-
вания, что добавляет еще один уровень защиты.
Сервис AWS KMS (Key Management Service) предоставляет функциональность
envelope encryption — безопасную среду, в которой ключи данных шифруют
данные клиентов, а главные ключи из KMS шифруют ключи данных. Сервис
обеспечивает централизованный контроль над управлением ключами, включая
пользовательский доступ и ротацию ключей.
AWS KMS — это мультитенантный модуль управления ключами. Другие про-
вайдеры облачных платформ предлагают похожие системы управления клю-
чами — например, GCP Cloud Key Management и Microsoft Azure Key Vault.
Иногда из-за нормативных требований клиенты предпочитают специализиро-
ванные хранилища ключей, включающие средства безопасности на уровне фи-
зического оборудования. В таком случае они могут принять решение о хранении
310 Глава 7. Факторы безопасности
своих ключей в аппаратном модуле безопасности (HSM, Hardware Security
Module). Облачные провайдеры (такие, как AWS) также представляют такие
хранилища — например, AWSCloudHSM. Вы также можете выбрать поставщика
HSM самостоятельно.
HSM — специализированное устройство, спроектированное для защиты крип-
тографических ключей и операций, представляющих защищенные механизмы
физической и логической безопасности. Оно спроектировано так, чтобы обнару-
живать попытки взлома и реагировать на них стиранием ключей. На логическом
уровне HSM применяет жесткий контроль доступа, предоставляя только автори-
зованным пользователям конкретные роли и взаимодействия с устройством. Для
предотвращения потери данных важно обеспечить высокую доступность HSM,
обычно посредством развертывания нескольких компонентов в разных местах.
Шифрование передаваемых данных
Под «передаваемыми данными» (data in transit) имеются в виду данные, пере-
даваемые по сети. Данные в покое (data at rest) могут шифроваться в источнике
и приемнике, но при передаче данных должен защищаться также канал, по
которому они передаются.
Когда данные передаются по незашифрованному протоколу (например, HTTP),
их можно перехватить посредством таких атак, как атака подслушиванием
(eavesdropping) или атака «человек посередине» (MITM, Man-In-The-Middle).
При атаке подслушиванием злоумышленник перехватывает небольшой пакет
из сети и использует его для поиска другого типа информации. Атака «человек
посередине» основана на фальсификации: злоумышленник тайно вмешивается
в передачу данных, чтобы отправить ответ от имени получателя. Атаки такого
рода предотвращаются передачей данных по протоколу SSL с использованием
сильного протокола — такого, как TSL (Transport Security Layer).
Заметим, что большинство веб-сайтов в наши дни использует для коммуникаций
протокол HTTPS, который шифрует данные с использованием SSL. По умолча-
нию трафик HTTP не защищается. Все веб-серверы и браузеры поддерживают
защиту SSL/TSL трафика HTTP (HTTPS). Трафик HTTP также используется
в таких сервис-ориентированных архитектурах, как REST (Representational State
Transfer) и архитектуры на базе SOAP (Simple Object Access Protocol).
Процедура рукопожатия (handshake) SSL/TSL использует сертификаты для
передачи открытого ключа с асимметричным шифрованием, а затем открытого
ключа для передачи закрытого ключа с симметричным шифрованием. Сертифи-
кат безопасности выдается одним из центров сертификации (СА, Certification
Authority) — например, Verisign. Полученные сертификаты безопасности долж-
ны защищаться при помощи PKI (Public Key Infrastructure). Ниже приведено
краткое описание стандартного процесса согласования SSL с использованием
обмена ключами RSA.
Выбор технологий для безопасности архитектуры 311
1. Сообщение от клиента (Client Hello): клиент инициирует обмен данными
SSL, отправляя сообщение серверу. Оно включает номер версии SSL, предпо-
чтительные параметры шифра и данные, относящиеся к сессии пользователя.
2. Ответ сервера (Server Hello): сервер реагирует на сообщение клиента, со-
глашаясь на обмен данными по протоколу SSL. Он проверяет номер версии
SSL и отправляет ее сертификат, содержащий открытый ключ.
3. Аутентификация и генерирование предварительного секрета: клиент про-
веряет подлинность сертификата сервера: его общее имя, период действия
и орган, выдавший сертификат. Затем он генерирует предварительный секрет,
основанный на выбранном шифре, и шифрует его открытым ключом, полу-
ченным от сервера перед отправкой.
4. Дешифрование и создание главного секрета: сервер использует свой за-
крытый ключ для дешифрования предварительного секрета. Обе стороны
используют предварительный секрет для создания главного секрета по схеме,
определяемой выбранным шифром.
5. Шифрование ключа сессии: как сервер, так и клиент отправляют сообще-
ния, указывающие, что последующие коммуникации будут шифроваться
с использованием ключа сессии, также называемого общим секретом. Они
подтверждают, что шифрование и дешифрование сообщений были успешны-
ми, гарантируя, что остальные коммуникации сессии надежно зашифрованы.
Передача данных по сети вне веб-приложений также должна шифроваться,
в том числе механизмами шифрования SSH (Secure Shell) и IPsec (Internet
Protocol security). SSH получил более широкое распространение для подклю-
чений к серверам, a IPsec применяется для защиты корпоративного трафика,
передаваемого по виртуальной частной сети (VPN). Передача файлов должна
защищаться при помощи протокола SFTPS (SSH File Transfer Protocol) или
FTPS (FTP Secure), а коммуникации серверов электронной почты должны за-
щищаться протоколом SMTPS (Simple Mail Transfer Protocol Secure) или IMAP
(Internet Message Access Protocol).
В этом разделе вы узнали о разных способах защиты хранимых и передаваемых
данных. Резервное копирование и восстановление данных — важнейший аспект
защиты данных при возникновении любых непредвиденных обстоятельств.
Резервное копирование данных более подробно рассматривается в главе 8
«Факторы надежности архитектуры».
Защита API
Интерфейсы программирования приложения, или API (Application
Programming Interface), — своего рода «соединительная ткань» между разны-
ми программными системами. API обеспечивают бесшовное взаимодействие
и передачу данных. API можно сравнить с официантом в ресторане. Вы (при-
ложение) передаете официанту (API) ваш заказ (запрос), а официант приносит
312 Глава 7. Факторы безопасности
заказанное блюдо (данные/ответ) из кухни (другой программной системы
или базы данных). Ввиду своей важнейшей роли в современных программных
инфраструктурах, особенно в облачных сервисах и микросервисных архитек-
турах, API стали заманчивой целью для кибератак. Как следствие, проблема
их защиты еще никогда не была настолько серьезной. API по самой своей
природе предоставляют шлюз к потенциально конфиденциальным функциям
и данным приложений. Без должной защиты API могут стать источником
угроз — например, несанкционированного доступа к чувстительным данным,
повреждения данных, отказа в обслуживании и даже взлома системы. Более
того, из-за взаимосвязей современных программных экосистем уязвимость
в одном API теоретически может поставить под удар целое семейство прило-
жений и сервисов. Так как бизнесы все сильнее зависят от API для интеграции
сторонних сервисов и подключения такой функциональности, как платежные
шлюзы, последствия взлома API могут быть очень серьезными, влияющими на
доход компании, ее репутацию и правовые вопросы.
Ниже перечислены некоторые практики по обеспечению безопасности API.
• Аутентификация и авторизация: используйте сильные методы аутентифика-
ции (такие, как OAuth или JWT) для идентификации сущностей, пытающихся
обратиться к API. Кроме того, реализуйте эффективные протоколы авториза-
ции для управления правами доступа. Это означает, что даже пользователи,
прошедшие аутентификацию, смогут обращаться только к тем данным или
функциям, к которым им это явно разрешено. Безопасный API знает, кто
выдает запрос и к чему этой сущности разрешено обращаться. Банковское
приложение использует API, чтобы пользователи имели возможность про-
верять баланс своего счета, и OAuth, чтобы только пользователи, прошедшие
аутентификацию и авторизацию, могли просматривать подробную инфор-
мацию о своих счетах.
• Ограничение частоты: реализуйте ограничение частоты для предотвращения
многих злоупотреблений, включая атаки методом «грубой силы» (брутфорса).
Ограничивая количество запросов, которые могут поступить от пользовате-
ля или IP-адреса за заданный промежуток времени, можно предотвратить
перегрузку системы вследствие потенциальных атак или попытки быстрого
перебора многих комбинаций. API интернет-магазина может запретить
пользователям выдавать более 10 запросов в минуту, чтобы предотвратить
перегрузку системы и потенциальные злоупотребления.
• Проверка ввода: всегда проверяйте и проводите очистку данных, отправляе-
мых вашему API. Тем самым вы можете предотвратить различные виды атак
(включая SQLi), при которых злоумышленник отправляет некорректные
данные в надежде манипулировать вашей системой. Представим, что форма
обратной связи в интернете использует API для отправки пользовательских
комментариев. Система проверяет, что введенные данные не содержат вре-
доносных скриптов, которые могут использоваться для взлома веб-сайта.
Выбор технологий для безопасности архитектуры 313
• Шифрование: данные, передаваемые API и возвращаемые ими, должны
шифроваться с использованием таких протоколов, как TLS. Это гарантирует,
что даже в случае перехвата пакетов данных злоумышленник не сможет их
прочесть. Приложение-мессенджер обеспечивает шифрование сообщений,
передаваемых между пользователями. Если кто-то перехватит сообщение,
он увидит только набор бессмысленных символов вместо реального содер-
жимого. Шифрование можно сравнить с общением на условном языке. Даже
если кто-то подслушает ваш разговор, он поймет его только в том случае,
если сам владеет этим языком.
• Регулярный мониторинг и аудит: непрерывно отслеживайте активность
API. Любые необычные закономерности — неожиданные пики запросов,
аномальные схемы обращений к данным — могут оказаться ранними при-
знаками атаки или эксплуатации уязвимости. Регулярный аудит также
поможет выявить ошибки в настройках безопасности. Провайдер облачных
платформ отслеживает свои API для выявления необычных схем передачи
данных: он следит, чтобы большие объемы данных не загружались и не от-
правлялись неожиданно, что может указывать на взлом. Представьте камеры
видеонаблюдения в магазинах — они наблюдают за происходящим и помогают
предотвращать кражи.
• Реализация шлюзов API: использование шлюзов API может стать дополни-
тельным уровнем защиты. Шлюзы обеспечивают маршрутизацию запросов,
компоновку API и другие функции, благодаря которым до бэкенд-систем
доберутся только проверенные запросы. Сайт интернет-магазина использует
шлюз API для управления запросами, чтобы к его базе данных поступали
только легитимные и должным образом структурированные запросы, а по-
тенциально вредоносные запросы отфильтровывались. Представьте портье
в гостинице, который проверяет и подтверждает бронь, прежде чем пропу-
стить гостя в номер.
• Обработка ошибок: избегайте раскрытия конфиденциальной информации
в сообщениях об ошибках. Пользователю должно возвращаться обобщенное
сообщение, а подробное описание должно безопасно храниться на стороне
сервера для диагностики. Когда пользователь пытается сбросить пароль,
а его адрес электронной почты не распознан системой, система не сообщает,
что адрес ошибочен или не существует. Она просто предлагает повторить
действие, предотвращая потенциальные попытки фишинга.
• Использование файрволов веб-приложений: WAF могут обнаруживать
и блокировать вредоносные запросы к API, предоставляя еще один уровень
защиты от типичных веб-угроз. Например, в случае интернет-магазина WAF
может анализировать входящий трафик к конечным точкам API, выявляя
и предотвращая потенциально вредоносные запросы — такие, как атаки SQEi
и XSS. Таким образом гарантируется обработка только легитимных запросов,
а приложение защищается от киберугроз.
314
Глава 7. Факторы безопасности
• Версионирование: реализуйте механизм версионирования API. Если в од-
ной версии API будет обнаружена проблема безопасности, ее можно будет
решить без влияния на другие версии, что обеспечит непрерывность работы
сервиса для приложений, использующих другие версии. Представим, что
у вас есть мобильное приложение, которое зависит от API для получения
пользовательских данных, и вы реализовали версионирование (например,
vl, v2, v3). Если в версии v2 будет обнаружена уязвимость безопасности, вы
можете быстро решить ее в этой версии, тогда как более старая (vl) и новая
(v3) версии продолжат работать безопасно. Такой подход позволяет группе
разработки устанавливать исправления или обновления для конкретных
версий API, сводя к минимуму последствия для конечных пользователей.
• Периодическое тестирование безопасности: периодически проводите тести-
рование API на проникновение и оценку уязвимостей. Такой проактивный
подход позволит выявить и исправить потенциальные слабости до того, как
ими воспользуются злоумышленники. Платформа музыкального стримин-
га периодически тестирует свой API, чтобы убедиться, что посторонние
пользователи не смогут получить доступ к премиальным возможностям без
соответствующей подписки.
Поскольку API — ключевое звено современных цифровых инфраструктур, не-
обходимость в их защите возрастает. Соблюдая лучшие отраслевые практики
и применяя проактивный подход, компании могут защитить свои операции,
клиентов и репутацию от возникающих угроз.
Ряд руководящих органов публикует нормативы, касающиеся безопасности
данных. Такие нормативы могут принимать форму контрольных списков с тре-
бованиями, которые необходимо соблюдать. Комплаенс также обеспечивается
соблюдением отраслевых и местных правил. Различные меры соответствия
рассматриваются в следующем разделе.
Сертификация безопасности и соответствия
Многие сертификаты соответствия, направленные на защиту конфиденциаль-
ности клиентов и безопасность данных, зависят от отрасли и географического
положения. В любом проектируемом решении требования к комплаенсу явля-
ются одними из важнейших для соблюдения. Ниже перечислены некоторые из
самых известных географических и отраслевых нормативов:
• К категории глобального соответствия относятся стандарты, которые должны
соблюдать все организации независимо от региона. К их числу принадлежат
ISO 9001, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3 и CSA
STAR для облачной безопасности.
• Правительство США требует соблюдения различных нормативов для работы
в государственном секторе. В частности, стандартов FedRAMP, DoD SRG
Level-2, 4 и 5, FIPS 140, NIST SP 800, IRS 1075, HTAR, VPAT и CJIS.
Модель общей ответственности за безопасность в облаке 315
• Конкретные отрасли требуют соответствия отраслевым стандартам в при-
ложении. К числу отраслевых стандартов относятся PCI DSS, CDSA, МРАА,
FERPA, CMS MARS-E, NHS IG Toolkit (в Великобритании), HIPAA, FDA,
FISC (в Японии), FACT (в Великобритании), Shared Assessment и GFBA.
• Сертификация соответствия региональным стандартам относится к кон-
кретной стране или региону. В частности, она подразумевает соответствие
стандартам GDPR (Евросоюз), Model Clauses (Евросоюз), G-Cloud (Вели-
кобритания), DJCP (Китай) MTCS (Сингапур), PDPA (Аргентина), IRAP
(Австралия), MeitY (Индия), GCIO (Новая Зеландия), CS Mark Gold (Япо-
ния), ENS и DPA (Испания), Privacy Law (Канада) и Privacy Shield (США).
Как видите, существует множество сертификатов соответствия, выдаваемых
различными регулирующими органами и касающихся отраслевой, региональ-
ной и государственной политики. Мы не будем углубляться в их детали, но вы
должны оценить свое приложение на соответствие нормам и стандартам еще
до начала его проектирования, так как эти требования оказывают значительное
влияние на общую архитектуру приложения. На основании требований к ком-
плаенсу необходимо подобрать подходящий вид шифрования, а также системы
ведения журнала и аудита и место размещения рабочей нагрузки.
@ Журналы и мониторинг помогают обеспечивать безопасность и комплаенс
и поэтому играют очень важную роль в приложениях. При возникновении
инцидента команда немедленно получит уведомление и будет готова
отреагировать. Методы мониторинга и оповещений рассматриваются
в главе 9 «Операционное совершенство».
Некоторые виды комплаенса зависят от геолокации приложения, а также от от-
расли и государственных правил. Вы узнали о различных категориях нормативов
и некоторых распространенных стандартах в каждой категории.
Обсудим теперь особенности облачной безопасности.
Модель общей ответственности
за безопасность в облаке
Поскольку облачные технологии становятся стандартом и многие организации
переносят свою рабочую нагрузку на публичные облачные платформы (такие,
как AWS, GCP и Azure), клиентам необходимо понимать облачную модель
безопасности.
Безопасность в облаке — это совместная ответственность клиента и провайдера
облачной платформы.
Обязанности клиента — безопасность решений, реализованных с использованием
облачных сервисов, и защита приложений в облаке. Уровень ответственности
клиента за безопасность приложений зависит от выбранного облачного про-
вайдера и от сложности системы.
316
Глава 7. Факторы безопасности
На рис. 7.11 представлена модель облачной безопасности от одного из самых круп-
ных провайдеров публичных облачных платформ (AWS), но ее в основном можно
применить к любому провайдеру — в частности, Azure, GCP, Oracle, IBM и Alibaba:
Данные клиента
Платформа, приложения, управление идентификационными данными и доступом
Ответственность клиента
Рис. 7.11. Модель общей ответственности за безопасность в AWS Cloud
Клиент обеспечивает безопасность в облаке, что подразумевает следующие зоны
ответственности.
• Операционная система сервера: ОС, установленная на сервере, может быть
уязвимой для атак. За установку патчей и поддержку операционной системы
отвечает клиент, так как от этого сильно зависят его приложения.
• Приложение: все приложения и их среды (разработки, тестирования, про-
дакшен) обслуживаются клиентом. Таким образом, за реализацию политики
паролей и управление доступом отвечает клиент.
• Файрволы операционной системы/хостов: клиент должен защитить всю
свою систему от внешних атак. Облачная платформа обеспечивает безопас-
ность в этой области, но клиенты должны применять IDS и IPS, добавляющие
дополнительный уровень безопасности.
• Сетевая конфигурация и группа безопасности: облачная платформа предо-
ставляет инструменты для создания сетевого файрвола, но выбор трафика,
который будет остановлен или пропущен, зависит от требований приложения.
Клиенты отвечают за определение правил файрвола для защиты их систем
от внешнего или внутреннего сетевого трафика.
• Клиентские данные и шифрование: защита данных относится к обязанно-
стям клиента, так как он лучше понимает ее необходимый уровень. Облачная
платформа предоставляет средства защиты данных за счет использования
Модель общей ответственности за безопасность в облаке 317
различных механизмов шифрования, но клиент отвечает за применение этих
средств и защиту своих данных.
Как видно из рис. 7.11, AWS и другие провайдеры публичных облачных плат-
форм отвечают за безопасность облака, особенно физической инфраструктуры,
в которой размещаются ресурсы. Эти средства безопасности охватывают ряд
ключевых областей.
• Дата-центры: в дата-центрах AWS применяются круглосуточные меры
безопасности, включая жесткое управление доступом (с двухфакторной
аутентификацией), ведение подробных журналов входа в систему с их
регулярным анализом и видеонаблюдение. Кроме того, AWS обеспечивает
безопасную утилизацию устройств хранения данных такими методами, как
размагничивание и физическое разрушение.
• Аппаратная инфраструктура: серверы, накопители и другие устройства,
лежащие в основе сервисов AWS. AWS обеспечивает безопасность и целост-
ность этого оборудования.
• Программная инфраструктура: операционные системы хостов, приложе-
ния сервисов и ПО виртуализации, используемое в сервисах AWS. AWS
поддерживает безопасность этого программного уровня, обеспечивая его
устойчивость перед угрозами.
• Сетевая инфраструктура: AWS защищает свою сетевую инфраструктуру,
которая включает маршрутизаторы, коммутаторы, балансировщики нагрузки,
файрволы, кабели и т. д. К этой категории мер безопасности также относится
непрерывный мониторинг внешних границ сети. AWS также обеспечивает
безопасные точки доступа и избыточную сетевую инфраструктуру для
предотвращения перебоев и повышения безопасности.
Чтобы приложение соответствовало отраслевым нормативам (например,
PCI-DSS для безопасности финансовых данных и GDPR для защиты данных
в Европе), необходимо проводить аудит жалоб уровня приложения. Публичная
облачная платформа предоставляет различные сертификаты соответствия, ко-
торые применимы к аппаратным частям под ее управлением. Клиент получает
дополнительную пользу от наследования безопасности и комплаенса, предо-
ставляемого облачным провайдером.
Облачная платформа предлагает целый ряд инструментов и сервисов для за-
щиты приложения в облаке, наряду со встроенной безопасностью на уровне
ИТ-инфраструктуры. Тем не менее клиент должен сам решить, как использо-
вать эти сервисы и защищать свое приложение в облаке. Облачная платформа
предоставляет улучшенную видимость и централизованный контроль над ИТ-
ресурсами, что способствует эффективному управлению и безопасности систем.
Безопасность — приоритет для любого решения, и архитектор решений должен
позаботиться о том, чтобы приложение было безопасным и защищено от любых
атак. Постарайтесь применять лучшие практики автоматизированной безопас-
ности там, где это возможно. Механизмы безопасности на программной основе
318 Глава 7. Факторы безопасности
могут значительно улучшить масштабируемость, экономическую эффективность
и общий уровень безопасности. Начните с создания специального эталонного
образа виртуального сервера, в который встраиваются стандарты безопасности.
В дальнейшем этот образ можно последовательно использовать для каждого но-
вого сервера, который вы развертываете, обеспечивая однородную безопасность
инфраструктуры. Кроме того, проектируйте всю инфраструктуру по шаблону,
который определяет ее и управляет ею. Такой подход позволяет реплицировать
освоенные лучшие практики в каждой новой среде, которую вы создаете.
Безопасность — это непрерывная и планомерная работа. Каждый инцидент
безопасности следует рассматривать как возможность улучшить приложение.
Надежный механизм безопасности должен включать средства аутентификации
и авторизации. Организации и приложения должны автоматизировать реакцию
на события безопасности и защищать инфраструктуру на нескольких уровнях.
Моделирование угроз
Моделирование угроз представляет собой структурированный механизм вы-
явления, оценки потенциальных угроз и назначения им приоритетов. Понимая
потенциальные угрозы, можно спроектировать и реализовать соответствующие
контрмеры для предотвращения, обнаружения или минимизации последствий
этих угроз. Такое моделирование часто используется в разработке ПО, но может
применяться и в других областях — например, в инфраструктуре и эксплуатации.
Нахлвем основные компоненты моделирования угроз.
• Представление системы: перед анализом угроз необходимо получить четкое
понимание системы. Для этого обычно требуется построить диаграммы или
модели архитектуры, компонентов, потоков данных и потенциальных точек
входа системы. Простой сайт интернет-магазина может включать фронтенд
для пользователей, бэкенд-сервер для обработки запросов, базу данных
с учетными данными пользователей и внешний платежный шлюз для пла-
тежей. Прежде чем запускать новую функциональность, которая позволяет
пользователям сохранять несколько адресов доставки, команда разработки
должна убедиться, что при этом не появятся новые дефекты безопасности.
Она строит диаграмму потоков данных, показывающую, как новая функцио-
нальность взаимодействует с существующей системой.
• Идентификация угроз: составьте список потенциальных угроз на основании
представления системы. Это можно сделать с помощью таких методик, как
STRIDE (спуфинг, фальсификация, отказ от ответственности, раскрытие
информации, отказ в обслуживании, повышение привилегий)1 и деревья
1 Аббревиатура STRIDE от Spoofing — спуфинг, Tampering — фальсификация,
Repudiation — отказ от ответственности, Information disclosure — раскрытие инфор-
мации, Denial of service — отказ в обслуживании, Elevation of privilege — повышение
привилегий. — Примеч. ред.
Моделирование угроз 319
атак. Для сайта интернет-магазина угрозы могут включать SQL-инъекции
(для доступа к базе данных), фишинг (для похищения учетных данных поль-
зователей) или DoS-атаки (для выведения сайта из строя). Команда также
понимает, что предоставление пользователям возможности сохранять адреса
может привести к их раскрытию при утечке данных. Эта угроза включается
в общий список.
• Анализ угроз: оцените потенциальные последствия и вероятность каждой
идентифицированной угрозы. Это может помочь определить приоритеты
угроз. Так, SQLi раскрывает большой объем чувствительных пользова-
тельских данных, а фишинговая атака затрагивает меньшее количество
пользователей, но она более вероятна. Команда разработки оценивает, что
утечка данных с раскрытием сохраненных адресов может привести к потере
доверия пользователей и потенциальным злоупотреблениям. Этой угрозе
присваивается высокая степень серьезности.
• Стратегия сокращения риска: для каждой идентифицированной угрозы
определите лучшие действия для сокращения риска. Например, добавле-
ние средств управления безопасностью, изменение системной архитектуры
или даже согласие на риск, если его потенциальные последствия прием-
лемы. Для предотвращения SQL-инъекции команда может использовать
параметризованные запросы, а для борьбы с фишингом — двухфакторную
аутентификацию. Для защиты адресов пользователей можно зашифровать их
в базе данных. Также можно добавить оповещения о любой подозрительной
активности, связанной с изменениями адресов.
• Документация: документируйте результаты, включая потенциальные угрозы,
их серьезность и выбранные стратегии сокращения рисков. Например, коман-
да создает документ, в котором указано, что адреса пользователей должны
шифроваться, а также приводится используемый метод шифрования. Через
шесть месяцев появляется требование о переходе на другую базу данных.
Документация поможет команде новой базы данных понять действующие
меры безопасности.
• Анализ и обновление: моделирование угроз не является разовым мероприя-
тием. С развитием систем могут появиться новые угрозы, а другие станут
менее актуальными. Регулярный анализ и обновление модели угроз гаран-
тируют, что она остается актуальной. Например, на сайт интернет-магазина
решено добавить новую функциональность: чат-бота. Перед ее развертыва-
нием команда обращается к своей модели угроз, чтобы узнать, приведет ли
реализация новой функциональности к появлению новых уязвимостей или
эволюции существующих угроз.
Моделирование угроз помогает командам действовать проактивно в части усилий
по обеспечению безопасности, исправляя потенциальные уязвимости до того,
как они станут проблемой.
320 Глава 7. Факторы безопасности
Итоги
В этой главе вы узнали о принципах применения лучших практик безопасности
в ходе проектирования решений. Эти принципы включают важные параметры
защиты приложения с использованием соответствующего управления доступом,
защиты данных и мониторинга.
Безопасность должна применяться на всех уровнях. Мы начали разговор
с аутентификации и авторизации пользователей, а затем вы узнали о примене-
нии безопасности на веб-уровне, а также уровнях приложения, инфраструкту-
ры и баз данных. Каждый уровень уязвим для разных атак, и вы познакомились
с разными методами защиты приложения и вариантами выбора технологий.
В области управления пользователями вы научились применять методы FIM
и SSO для корпоративных пользователей, а также методы реализации аутентифи-
кации и авторизации пользователей. К их числу относятся такие корпоративные
сервисы управления, как Microsoft AD и AWS Directory Service. OAuth 2.0 дает
возможность обслуживать миллионы пользователей.
Вы узнали о таких типах атак на веб-уровне, как DDoS, SQLi и XSS. Вы научи-
лись защищаться от этих атак с помощью различных методов их предотвращения
и с помощью сетевых файрволов. Вы освоили методы защиты кода на уровне
приложения и обеспечения безопасности инфраструктуры. Далее мы подробно
рассмотрели различные сетевые компоненты и методы формирования доверен-
ных границ для ограничения радиуса атаки.
Вы узнали, как организовать защиту данных путем их правильной классифи-
кации и пометкой данных как конфиденциальных, приватных или публичных.
Были рассмотрены симметричные и асимметричные алгоритмы шифрования
и различия между ними. Вы узнали о методах управления ключами для защиты
открытых/закрытых ключей шифрования. Данные могут передаваться по сети
или находиться в хранилище — мы рассмотрели защиту данных в обоих режи-
мах. Мы исследовали безопасность API и лучшие практики обеспечения без-
опасности всех API, через которые осуществляются обращения к приложению.
Далее рассматривались различные модели общей ответственности и комплаенса,
применимые к облачным рабочим нагрузкам. Глава завершилась описанием
моделирования угроз.
Эта глава была посвящена применению лучших практик безопасности. Другой
критически важной характеристикой дизайна любого решения является надеж-
ность. Чтобы бизнес был успешным, необходимо создать надежное решение, ко-
торое будет постоянно доступным и справится с колебаниями рабочей нагрузки.
В следующей главе будут представлены лучшие практики, которые обеспечат
надежность приложения, а также доступные для этого технологии. Вы узнаете
о стратегиях аварийного восстановления и репликации данных, которые повы-
шают надежность приложений.
ГЛАВА 8
ФАКТОРЫ НАДЕЖНОСТИ
АРХИТЕКТУРЫ
Надежность приложений — неотъемлемый аспект проектирования архитектуры,
жизненно важный для успеха любого бизнеса.
Надежностью (reliability) называется способность системы восстанавливаться
при сбоях. Суть ее в том, что приложение отказоустойчиво и способно восста-
навливаться после любых сбоев инфраструктуры или серверов без последствий
для пользовательского опыта. Система должна быть готова к любой ситуации,
которая может привести к нарушению работоспособности.
Так как все компании сейчас работают в интернете, высокая доступность (high
availability) тоже стала обязательным критерием для онлайн-приложений.
Пользователи хотят иметь возможность открыть приложение в любой момент
и совершать покупки в интернете или банковские операции тогда, когда им это
удобно.
В этой главе рассматриваются принципы проектирования, повышающие надеж-
ность решений. При оценке надежности необходимо учитывать все компоненты
архитектуры. Вы поймете, как выбрать правильную технологию для обеспечения
надежности архитектуры на всех уровнях.
В этой главе рассматриваются следующие темы.
• Принципы проектирования для надежности архитектуры.
• Выбор технологии для надежности архитектуры.
• Повышение надежности на облачных платформах.
К концу главы вы будете знать различные методы аварийного восстановления
и методы репликации данных, обеспечивающие высокую доступность прило-
жения и непрерывность бизнес-процессов.
322 Глава 8. Факторы надежности архитектуры
Принципы проектирования для надежности
архитектуры
Надежность и высокая доступность — основные факторы, гарантирующие, что
приложения и инфраструктура смогут удовлетворять пользовательские потреб-
ности без перебоев. Надежность фокусируется на способности системы работать
корректно в конкретных условиях и в конкретный период времени.
Надежность подразумевает проектирование систем таким образом, чтобы любые
сбои изолировались в минимально возможной области, сокращая последствия для
эксплуатации в целом. Этот подход требует исчерпывающего понимания потенци-
альных сбоев и реализации целенаправленных стратегий минимизации рисков либо
для предотвращения таких сбоев, либо для корректного восстановления после них.
Высокая доступность, подробно рассматриваемая в главе 2, тесно связана
с надежностью, но с особым вниманием к обеспечению доступности сервисов
в любой момент времени. Стратегии высокой доступности включают создание
избыточных систем и компонентов для устранения единых точек сбоев, тем
самым обеспечивая бесшовное подключение резерва в случае сбоя. Целью
является поддержание работоспособности сервиса даже в случае аппаратных
сбоев, нарушения работы сети или программных ошибок. Интегрируя надеж-
ность и высокую доступность в системную архитектуру, организации могут быть
уверены, что их приложения защищены от сбоев и поддерживают согласован-
ность уровней обслуживания.
Мы обсудим стандартные принципы проектирования, которые помогают укре-
пить надежность системы. Вы увидите, что все принципы проектирования на-
дежности тесно связаны между собой и дополняют друг друга.
Самовосстановление систем за счет применения
автоматизации
Интеграция функциональности самовосстановления и автоматизации в архитек-
туру системы повышает ее надежность, так как система может прогнозировать
сбои и восстанавливаться после них автоматически. Самовосстанавливающаяся
система активно обнаруживает и устраняет сбои между разными уровнями систе-
мы (будь то оборудование, сеть или программы), минимизируя последствия для
конечных пользователей. Такой подход требует определения критически важных
ключевых показателей эффективности (KPI, Key Performance Indicators) для
приложения и бизнес-операций — например, количества обрабатываемых запро-
сов в секунду или времени загрузки веб-страницы. KPI уровня инфраструктуры
может включать пороги загрузки процессора и памяти, гарантирующие, что они
не превысят заранее определенные лимиты.
Для достижения самовосстанавливающейся архитектуры реализуйте эффек-
тивную систему мониторинга, которая отслеживает показатели KPI и выдает
Принципы проектирования для надежности архитектуры 323
оповещения при достижении критических порогов. Такая система должна под-
держиваться стратегиями автоматизации, которые могут, например, запустить
дополнительные серверы для управления повышенной нагрузкой, когда загрузка
процессора приближается к максимально допустимому проценту. Такой уровень
активного мониторинга и автоматизированных реакций не только предотвращает
потенциальные сбои, но и помогает обеспечивать оптимальные уровни произ-
водительности без ручного вмешательства.
Кроме того, включение автоматизации в жизненный цикл приложения — от
развертывания и конфигурации до масштабирования инфраструктуры — форми-
рует более адаптивную и устойчивую среду. Автоматизация позволяет команде
быстро развертывать новую функциональность, более свободно эксперименти-
ровать и обеспечивать стабильную производительность системы независимо
от колебаний рабочей нагрузки. Автоматизация масштабирования ресурсов
на основании запланированного спроса или неожиданных выбросов трафика
гарантирует, что приложение останется отзывчивым и доступным.
Применяя автоматизацию для развертывания независимых заданий и агрегируя
их результаты, можно не только добиться повышения надежности и эффек-
тивности, но и улучшить способность системы к самовосстановлению после
инцидентов. Это делает вашу инфраструктуру по-настоящему устойчивой
и самоподдерживаемой.
Контроль качества
Настройки среды разработки часто применяются и в средах контроля качества
(QA, Quality Assurance). При этом для каждого этапа тестирования может быть
несколько QA-сред, включая среды функционального, приемочного (UAT, User
Acceptance Testing) и стрессового тестирования.
Нередко QA-тестировщик обнаруживает дефект, обусловленный неправильной
настройкой ресурсов, что может создать дополнительную задержку в графике
тестирования. Что еще важнее, ошибки конфигурации недопустимы на рабочих
серверах, где они могут породить массовые сбои, поэтому лучше тестировать
их заранее.
Чтобы воспроизвести в среде QA точно такую же конфигурацию, как в среде
разработки, необходимы подробные документальные инструкции по настройке.
Ручное повторение одних и тех же действий для настройки каждой среды мо-
жет быть слишком ненадежным. Всегда существует вероятность человеческой
ошибки — например, опечатки в имени базы данных. Проблема решается авто-
матизацией этих действий в скрипте. Скрипт автоматизации сам по себе может
служить документацией.
Правильно написанный скрипт надежнее ручной настройки. И безусловно,
он лучше воспроизводится. Процессы обнаружения неработоспособных ре-
сурсов и запуска резервных ресурсов-заменителей можно автоматизировать,
чтобы команда ИТ-операций получала уведомления об изменении ресурсов.
324 Глава 8. Факторы надежности архитектуры
Автоматизация — фундаментальный принцип проектирования, который должен
применяться в системе повсеместно.
Создание распределенной системы
Монолитные приложения обладают низкой надежностью в отношении времени
работоспособности, так как незначительная проблема в одном модуле может
вывести из строя всю систему. Разделение приложения на несколько небольших
сервисов сокращает зону поражения. Одна часть приложения не влияет на си-
стему в целом, а само приложение сохраняет критическую функциональность.
Например, на сайте интернет-магазина проблема с платежным сервисом не
должна влиять на способность клиента к размещению заказов, так как оплата
может быть произведена позднее.
На уровне сервисов масштабируйте приложение горизонтально в целях улучше-
ния доступности системы. Для сокращения зоны поражения проектируйте систе-
му так, чтобы она использовала несколько меньших компонентов, работающих
совместно, вместо одной монолитной системы. В распределенной архитектуре
запросы обрабатываются разными системными компонентами, а сбой одного
компонента не влияет на функционирование других частей системы. Например,
на сайте интернет-магазина сбой компонентов управления складскими запасами
не повлияет на возможность клиента оформлять заказы.
Тем не менее в распределенной системе механизм коммуникаций может быть
достаточно сложным. Эта сложность возникает из-за того, что необходимо
обеспечить надежный обмен данными между компьютерами, объединенными
в сеть, на каждом из которых может выполняться своя операционная система,
и все они могут размещаться в разных географических регионах. Среди проблем
можно выделить сетевую задержку, гарантии доставки сообщений, синхрони-
зацию данных между узлами для обеспечения согласованности и реализацию
отказоустойчивости для преодоления частичных отказов системы. Кроме того,
сложность повышают разработка и обслуживание коммуникационного протоко-
ла, эффективно поддерживающего разнообразные требования распределенной
архитектуры.
Паттерн «Предохранитель» (Circuit Breaker) может помочь с решением проблем
зависимостей между системами. Как вы узнали из описания этого паттерна
в главе 4 «Паттерны проектирования архитектур решений», базовая идея про-
ста. Защищаемый вызов функции упаковывается в объект-«предохранитель»,
который отслеживает сбои и предпринимает автоматизированные действия по
сокращению их последствий.
Мониторинг и добавление емкости
Истощение ресурсов — основная причина сбоев приложений. Часто про-
блемы возникают, когда приложения начинают отклонять запросы из-за
Принципы проектирования для надежности архитектуры 325
перегруженности процессора, памяти или жесткого диска. В традиционной ло-
кальной среде можно вычислить серверную емкость на основании опережающих
предположений. Сетевой трафик крайне непредсказуем и подвержен заметным
колебаниям, зависящим от глобальных тенденций. Обычно приобретение обо-
рудования занимает от 3 до 6 месяцев, и спрогнозировать емкость заранее до-
статочно сложно. Заказ лишнего оборудования создает дополнительные затраты,
так как ресурсы простаивают, а их нехватка приводит к потерям бизнеса из-за
ненадежности приложения. Нужна среда, в которой не требуется прогнозировать
емкость, а приложение может масштабироваться по требованию.
Провайдер публичных облачных структур — такой, как AWS — предоставляет
инфраструктуру как сервис (laaS), облегчая доступность ресурсов по требова-
нию. В облаке можно отслеживать обеспеченность и потребность систем. Можно
автоматизировать добавление или удаление ресурсов по мере надобности. Оно
позволяет поддерживать уровень ресурсов, который удовлетворит потребность
без чрезмерного или недостаточного резервирования.
Проверка восстановления при сбоях
Когда дело доходит до проверки инфраструктуры, в большинстве случаев ор-
ганизации концентрируются на проверке так называемого счастливого пути
(happy path), на котором все работает. Однако на самом деле следует проверять
возможные сбои и эффективность процедур восстановления. Проверяйте при-
ложение исходя из того, что ошибки будут возникать везде, где только можно. Не
ожидайте, что реализованные стратегии восстановления и преодоления отказов
будут работать. Не забывайте регулярно тестировать их. Если что-то пойдет не
так, это не станет для вас сюрпризом.
Проверка, основанная на моделировании, поможет выявить потенциальные
риски. Можно автоматизировать сценарий, который приведет к сбою системы,
и подготовить соответствующую реакцию на инцидент. Проверка должна повы-
сить надежность приложения, чтобы исключить сбои в рабочей среде.
Иногда проектировщики упускают из вида такую важную составляющую
доступности, как восстанавливаемость. Чтобы улучшить показатели RPO
(Recovery Point Objective — целевая точка восстановления) и RTO (Recovery
Time Objective — целевое время восстановления), следует создавать резерв-
ные копии данных и приложений и их конфигураций в виде образа машины.
Вы больше узнаете о RTO и RPO в следующем разделе. Представим, что в ре-
зультате стихийного бедствия один или несколько компонентов становятся
недоступными или основной источник данных уничтожается. В таком случае
необходимо иметь возможность восстановить сервис быстро и без потери дан-
ных. В следующем разделе рассматриваются конкретные стратегии аварийного
восстановления, улучшающие надежность приложения, и связанный с ними
выбор технологии.
326 Глава 8. Факторы надежности архитектуры
Выбор технологии для архитектурной
надежности
Надежность приложения часто рассматривается как доступность приложения
для обслуживания пользователей. Совокупность факторов обеспечивает высокую
доступность. А под отказоустойчивостью (fault tolerance) понимается встроенная
избыточность компонентов приложения. Приложение может обладать высокой
доступностью, но не 100 %-ный отказоустойчивостью. Например, если приложе-
нию нужны четыре сервера для обработки запроса пользователя, их делят между
двумя дата-центрами для обеспечения высокой доступности. Если один центр
выходит из строя, система сохраняет доступность на уровне 50 %, но это может
повлиять на ожидания пользователей относительно производительности. Но если
создать равную избыточность в обоих центрах с четырьмя серверами в каждом,
приложение будет не только высокодоступным, но и на 100 % отказоустойчивым.
Предположим, приложение не обладает 100 % отказоустойчивостью. В таком
случае следует добавить автоматизированную масштабируемость, определив,
как инфраструктура будет реагировать на увеличение нагрузки, чтобы гаран-
тировать доступность приложения и соответствие требуемым стандартам про-
изводительности.
Чтобы приложение являлось надежным, сервисы должны восстанавливаться
быстро и без потери данных. Забегая вперед, скажем, что этот процесс называ-
ется аварийным восстановлением (DR, Disaster Recovery). Прежде чем пере-
ходить к сценариям аварийного восстановления, рассмотрим подробнее RTO/
RPO и репликацию данных как ключевой фактор оценки при планировании
аварийного восстановления.
Планирование RPO и RTO
Бизнес-приложения должны определять доступность сервиса в форме соглаше-
ния об уровне обслуживания, или SLA (Service-Level Agreement). Организации
определяют SLA, чтобы обеспечить доступность и надежность приложения для
своих пользователей. Например, в SLA можно указать, что приложение должно
обладать 99,9 %-ной доступностью в таком-то году или что в организации до-
пустим простой продолжительностью 43 минуты в месяц и т. п. SLA определяет
также уровни RPO и RTO для приложения.
RPO — максимальный объем потери данных, который организация готова по-
терять за указанный период. Представим, что приложение может позволить себе
потерю данных за 15 минут. Если обработка заказов клиентов выполняется каж-
дые 15 минут, то в случае сбоя системы эти данные можно будет обработать по-
вторно. RPO помогает сформировать стратегию резервного копирования данных.
RTO — время простоя приложения и время, которое потребуется приложению
для восстановления и нормального функционирования после инцидента или
сбоя. На рис. 8.1 показаны различия между RTO и RPO.
Выбор технологии для архитектурной надежности 327
Например, сбой произошел в 10:00, а последнее резервное копирование прово-
дилось в 9:00; тогда в случае сбоя системы вы потеряете данные за 1 час. При
восстановлении системы будут потеряны данные за 1 час, так как резервное
копирование проводится ежечасно.
В этом случае RPO системы составляет 1 час, так как она способна пережить
потерю данных за 1 час. Если системе требуется 30 минут для восстановления
резервной копии и запуска системы, это означает, что RTO в ней составля-
ет 0,5 часа. Иначе говоря, максимальное приемлемое время простоя равно
30 минутам. RTO определяется временем, необходимым для восстановле-
ния всей системы после сбоя, приводящего к простоям; в данном случае это
30 минут.
Организации обычно определяют допустимые RPO и RTO на основании
пользовательского опыта и финансовых или репутационных последствий для
бизнеса в случае недоступности системы. Решения эффективного восстанов-
ления системы планируются в соответствии с определенными RTO и RPO.
С течением времени следует стремиться к сокращению RTO/RPO, что напря-
мую способствует повышению прибыли, так как приложение будет работать
в течение большего времени.
Данные играют ключевую роль в восстановлении системы. Рассмотрим неко-
торые методы сокращения их потери.
Репликация данных
Репликация данных и снапшоты чрезвычайно важны для DR (аварийного вос-
становления) и обеспечения надежности системы. Репликация создает копию
данных с основного хранилища в резервном (в резервной локации). В случае
отказа основной системы приложение переключается на резервную и продол-
жает надежно работать. Это могут быть файлы, хранящиеся на накопителе NAS,
снапшоты базы данных или образа машины. Хранилища могут быть двумя гео-
графически удаленными локальными системами, двумя разными устройствами
в одной локальной среде или физически разделенными элементами публичной
облачной платформы.
328 Глава 8. Факторы надежности архитектуры
Репликация данных полезна не только для DR, но и для повышения адаптив-
ности организации за счет быстрого создания новой среды для тестирования
и разработки. Репликация данных может быть синхронной или асинхронной.
Синхронная и асинхронная репликация
При синхронной репликации создается копия данных в реальном времени. Ре-
пликация в реальном времени позволяет сократить RPO и повысить надежность
в случае сбоя. Однако это повышает затраты, так как требует дополнительных
ресурсов в основной системе для непрерывной репликации данных.
Асинхронная репликация создает копии данных с небольшой задержкой или
по определенному графику. Зато она обходится дешевле, так как расходует
меньше ресурсов, чем синхронная. Выбирайте асинхронную репликацию, если
ваша система может работать с более продолжительным RPO.
С такими технологиями баз данных, как Amazon RDS, синхронная реплика-
ция применяется при создании RDS с несколькими зонами доступности (AZ,
Availability Zone). Такая конфигурация гарантирует, что основная база данных
и ее реплика в другой зоне доступности всегда будут синхронизированы, обе-
спечивая высокую доступность и стабильность данных. Если у основной базы
данных возникнут проблемы, сервис может автоматически переключиться
на реплику с минимальным прерыванием работоспособности. С репликами
для чтения применяется асинхронная репликация, и они могут использоваться
для предоставления отчетов и обслуживания запросов для чтения.
Как показано на рис. 8.2, при синхронной репликации отсутствует задержка
репликации данных между основным и резервным экземплярами базы данных,
а в случае асинхронной репликации может наблюдаться некоторая задержка при
репликации между основным и реплицированным экземплярами.
Синхронная репликация данных
Основной
экземпляр
Разность по времени = 0 ms
Резервный
экземпляр
Асинхронная
Основной
экземпляр
Рис. 8.2. Синхронная и асинхронная репликация данных
Выбор технологии для архитектурной надежности 329
Рассмотрим некоторые методы репликации данных для синхронных и асин-
хронных решений.
Методы репликации
Методом репликации называется способ извлечения данных из исходной си-
стемы и создания копии для целей восстановления данных. Репликации могут
быть реализованы следующими способами.
• Репликация на базе массива хранения: в этом случае данные автоматиче-
ски реплицируются встроенным программным обеспечением. Однако для
репликации данных исходный и приемный массив хранения должны быть
совместимыми и однородными. Массив содержит несколько дисковых на-
копителей на стойке.
Крупные организации применяют репликацию на базе массивов хранения для
упрощения развертывания и сокращения вычислительной мощности хост-
системы. Доступны такие продукты репликации на базе массивов хранения,
как HP Storage, EMC SAN Copy и NetApp SnapMirror.
• Репликация на базе сети: этот метод копирует данные между разными видами
разнородных массивов хранения. Для репликации данных между несовме-
стимыми массивами хранения используется дополнительный коммутатор
или компонент. При сетевой репликации затраты на репликацию могут быть
выше, так как в процессе участвует несколько сторон. Доступны такие про-
дукты сетевой репликации, как NetApp Replication X и EMC RecoverPoint.
• Репликация на базе хоста: в этом случае на хосте устанавливается про-
граммный агент, который может реплицировать данные в любой системе
хранения — такой, как NAS, SAN или DAS. Можно использовать хостовое
ПО от поставщика — например, Symantec, Commvault, С А или Vision Solution.
Этот способ чаще востребован малым и средним бизнесом из-за низких на-
чальных затрат и совместимости разнородных устройств. С другой стороны,
он требует более высоких вычислительных мощностей, так как агент должен
быть установлен в операционной системе хоста.
• Репликация на базе гипервизора: этот метод работает на уровне виртуальной
машины (VM), то есть копирует всю виртуальную машину с одного хоста на
другой. Так как организации в основном используют виртуальные машины,
этот метод предоставляет очень эффективный способ аварийного восстановле-
ния для сокращения RTO. Репликация на базе гипервизора обладает высокой
масштабируемостью и потребляет меньше ресурсов, чем репликация на базе
хоста. Она может выполняться в системах, встроенных в VMWare и Microsoft
Windows. Для выполнения репликации на базе гипервизора можно выбрать
такой продукт, как Zerto, или другой от альтернативных поставщиков.
В главе 2 «Принципы проектирования архитектуры решений» мы говорили
о масштабируемости и отказоустойчивости. В главе 4 «Паттерны проектирования
архитектур решений» вы узнали о паттернах проектирования, обеспечивающих
330 Глава 8. Факторы надежности архитектуры
высокую доступность архитектуры. Теперь рассмотрим некоторые способы
восстановления системы после сбоев и обеспечения ее высокой доступности.
Планирование DR
Целью аварийного восстановления (DR) является продолжение работы системы
при сбоях. DR должно подготовить организацию к любым возможным просто-
ям системы и предоставить возможность вывода системы из этого состояния.
Планирование DR охватывает сразу несколько измерений, включая аппаратные
и программные сбои.
@При планировании аварийного восстановления всегда учитывайте как
проблемы, связанные с деятельностью организации (сбои электроснабжения,
неработоспособность сети, сбои систем обогрева и охлаждения, физические
нарушения безопасности), так и другие инциденты: пожары, наводнения,
человеческий фактор и т. д.
Организации тратят значительные усилия и средства на планирование DR
в зависимости от критичности системы и последствий ее неработоспособности.
Приложение, напрямую генерирующее доход, должно работать постоянно, так
как оно влияет на имидж компании и прибыльность бизнеса. Для таких прило-
жений организации тратят значительные усилия на создание инфраструктуры
и обучение персонала действиям в случае аварии. DR — своего рода страховой
полис, который требует расходов по продлению даже тогда, когда вы его не
используете; с другой стороны, в критической ситуации план аварийного вос-
становления может стать спасительным для бизнеса.
Основные критически важные элементы — такие, как приложения — можно
разместить на условном спектре сложности. Существуют четыре сценария DR,
которые перечислены ниже в порядке убывания RTO/RPO:
• резервное копирование и восстановление;
• Pilot light («запал»);
• теплый резерв;
• горячий резерв.
Как видно из следующей диаграммы (рис. 8.3), при планировании DR с каждым
вариантом RTO и RPO убывают, а стоимость реализации растет. Необходимо
выдержать баланс между требованиями RTO/RPO и затратами на обеспечение
требований к надежности.
Сокращение RTO и RPO
Резервное копирование
и восстановление
Pilot
light
Горячий
резерв
Теплый
резерв
~~I
Сокращение затрат
Рис. 8.3. Спектр вариантов аварийного восстановления
Выбор технологии для архитектурной надежности 331
DR-стратегии определяются специфические потребности каждой организации.
Решение о полном переключении на резервную систему зависит от различных
критических факторов. Порог срабатывания может варьироваться от незначи-
тельных сбоев до масштабных катастроф, например физического разрушения
дата-центра. В случае катастрофы организации необходимо быстро провести
оценку и назначить приоритеты критическим сервисам; обычно это сервисы,
отвечающие за значительную часть дохода. У этих приоритетных сервисов мо-
жет быть заранее определенное значение RTO — например, 24-часовое окно для
возобновления операций, прежде чем финансовые последствия станут слишком
серьезными и приведут к таким потенциальным потерям, как штрафы, нарушения
SLA и падение продаж. С другой стороны, для менее катастрофических, но все
еще критических нарушений работоспособности компания может установить ав-
томатические протоколы преодоления отказов с существенно меньшим временем
допустимых простоев — например, 15 минут. В обоих сценариях критерии при-
нятия решений по аварийному восстановлению включают анализ последствий
для бизнеса, понимание RTO и RPO для важнейших сервисов, оценку затрат на
простои относительно процесса восстановления и проверку соответствия нор-
мативным требованиям. Кроме того, важнейшую роль в определении должных
мер реагирования, обеспечивающих непрерывность операций и сокращение
перебоев в эксплуатации, играют технические возможности, включая доступ-
ность и готовность вторичных площадок.
Рассмотрим каждый из упомянутых вариантов более подробно, включая выбор
соответствующих технологий. Учитывайте, что публичные облачные платформы
(такие, как AWS) позволяют применять все упомянутые DR-стратегии эффек-
тивно и экономично.
Резервное копирование и восстановление
Резервное копирование и восстановление — самый дешевый способ, для которого
характерны более высокие RPO и RTO. Этот метод легко внедряется и обладает
высокой экономической эффективностью, поскольку он требует только про-
странства для хранения резервных копий. Резервные копии могут храниться
на магнитных лентах, жестких дисках или накопителях NAS. Если хранилище
потребуется расширить, добавить и обслуживать новое оборудование в разных
регионах может быть непросто. Одно из самых экономически эффективных
и простых решений — использование облака в качестве среды хранения. При-
мером может служить Amazon S3; этот сервис предоставляет неограниченную
емкость хранения при небольших затратах и с моделью оплаты по фактическому
использованию.
На рис. 8.4 изображена базовая система аварийного восстановления. Данные хра-
нятся в традиционном дата-центре, а резервные копии — в AWS. Для перенесения
данных в AW используются жесткие диски AWS Import/Export или Snowball
емкостью от 8 до 100 Тбайт, после чего информация сохраняется в Amazon S3.
332 Глава 8. Факторы надежности архитектуры
Рис. 8.4. Резервное копирование данных в Amazon S3 из локальной
инфраструктуры
Можно использовать и другие сторонние решения резервного копирования.
Самые популярные варианты — NetApp, VMware, Tivoli и Commvault.
При планировании DR в облачной среде важно внедрить стратегии, исполь-
зующие преимущества облачных платформ — таких, как AWS, Google Cloud
Platform (GCP) и Microsoft Azure. Это обеспечивает гибкость и устойчивость
между разными платформами. Обобщенная процедура взаимодействия между
этими облачными сервисами выглядит так.
• Решения резервного копирования и восстановления: используйте сервисы
облачного хранения для размещения резервных копий систем. Для AWS на-
дежным сервисом хранения резервных копий может стать Amazon S3. В GCP
Google Cloud Storage предлагает надежное хранилище объектов с высокой
доступностью. Эквивалентный сервис Azure — Azure Blob Storage — предо-
ставляет аналогичный сервис для хранения больших объемов неструктури-
рованных данных.
• Образы машин и конфигурация: подготовьте образы машин, включающие
операционную систему, приложения и конфигурацию. AWS использует
образы AMI (Amazon Machine Image), GCP использует образы Compute
Engine, a Azure — образы Azure Virtual Machine. Эти образы можно изменить
и дополнить необходимыми патчами ПО и безопасности, чтобы они были
готовы к развертыванию в случае происшествия.
Выбор технологии для архитектурной надежности 333
• Документация восстановления системы: четко документируйте действия,
необходимые для восстановления системы из резервных копий на разных
облачных платформах. В документации должен быть описан процесс раз-
вертывания хранимых образов машин и восстановления баз данных и при-
ложений из резервных копий.
• Маршрутизация трафика и процедуры отработки отказов: опишите про-
цесс перенаправления трафика с основной площадки на резервную в облаке.
AWS предоставляет сервис Route 53 для управления DNS и маршрутизации
трафика, в GCP имеются Cloud DNS и Traffic Director, a Azure предоставляет
Azure Traffic Manager и DNS Zone. Очень важно уметь пользоваться этими
сервисами в контексте сценариев обработки отказов.
• Перечень задач: разработайте исчерпывающий перечень задач с подробным
описанием конфигураций развертывания, а также потенциальных проблем
и путей их решения. Документ должен быть облачно-нейтральным и адапти-
руемым к специфике AWS, GCP и Azure. Тем самым обеспечивается готов-
ность команд к действию независимо от используемой облачной платформы.
На этапе подготовки создайте и сохраните специализированные образы машин
и резервные копии в соответствующих облачных хранилищах — S3 для AWS,
Cloud Storage для GCP и Blob Storage для Azure. Также подготовьте снапшоты
баз данных, томов хранения данных и всех важнейших файлов. Такой про-
активный подход гарантирует, что независимо от облачного провайдера ваша
организация сможет быстро восстановиться в случае сбоя с минимальными
простоями и потерями данных.
Эта схема DR легко настраивается и обходится относительно недорого. Тем
не менее такой сценарий предполагает высокие значения RPO и RTO; RTO
будет равно времени простоя до момента, когда система будет восстановлена
из резервной копии и начнет функционировать, тогда как потери RPO зависят
от частоты резервного копирования системы. Рассмотрим следующий метод —
Pilot light — улучшающий RTO и RPO.
Pilot light
Pilot light («запал») — следующий по экономичности метод DR после описан-
ного выше. Подобно запалу в газовой колонке — небольшому огоньку, который
горит постоянно и может быстро зажечь всю колонку, — этот метод позволяет
поддерживать минимальное количество базовых сервисов, работающих в разных
регионах. В случае отказа можно быстро запустить дополнительные ресурсы.
Можно активно реплицировать уровень базы данных, а затем запускать экзем-
пляры по образам виртуальных машин или строить инфраструктуру по принципу
«инфраструктура как код» — например, CloudFormation, Terraform, Ansible и т. д.
На рис. 8.5 изображена схема DR по методу Pilot light. В данном случае база
данных реплицируется в AWS; экземпляры веб-серверов и серверов приложения
в Amazon ЕС2 готовы к работе, но в настоящее время не запущены.
334
Глава 8. Факторы надежности архитектуры
Локальное размещение
Пользователь
Amazon S3 Route 53
Hosted Zone
Веб-сервер
Сервер приложения
Сервер базы данных
Зеркало/репликация данных
Е Облако AWS
Сервер базы данных
V. SI
Рис. 8.5. Репликация данных в схеме Pilot light
Сценарий Pilot light напоминает сценарий резервного копирования и восстанов-
ления, в котором создается резервная копия большинства компонентов и они
сохраняются пассивно. С другой стороны, активные экземпляры поддерживаются
с более низкой емкостью критических компонентов (например, серверов баз
данных или серверов аутентификации), запуск которых может занимать заметное
время. Все необходимые ресурсы должны запускаться автоматически, включая
необходимые сетевые конфигурации, балансировщики нагрузки и образы вир-
туальных машин. Так как все основные части уже запущены, восстановление
происходит быстрее, чем в случае резервного копирования и восстановления.
Метод Pilot light очень экономичен, так как на полной мощности работает лишь
часть ресурсов.
Необходимо разрешить репликацию всех критически важных данных на пло-
щадке DR — в данном случае в облаке AWS. Для репликации данных между
локальной и облачной базами данных можно использовать сервис AWS Data
Migration Service. Для файловых данных можно воспользоваться сервисом
Amazon File Gateway.
Многие сторонние инструменты предоставляют эффективные решения
репликации данных- например, Attunity, Quest, Syncsort, Alooma и JumpMind.
Выбор технологии для архитектурной надежности 335
Если в основной системе произойдет сбой, как показано на рис. 8.6, можно за-
пустить экземпляры Amazon ЕС2 с новейшей копией данных. Затем Amazon
Route 53 перенаправляется на новый веб-сервер.
Пользователь
Рис. 8.6. Восстановление методом Pilot light
При использовании метода Pilot light в случае сбоя необходимо выполнить
следующие действия.
1. Запустите приложение и веб-серверы, находящиеся в резервном режиме.
Также масштабируйте серверы приложения горизонтально с использованием
балансировщика нагрузки.
2. Проведите вертикальное масштабирование экземпляра базы данных, рабо-
тавшего на низкой мощности.
3. Обновите запись DNS в маршрутизаторе, чтобы она указывала на новое
местоположение.
В методе Pilot light вы автоматически запускаете ресурсы, необходимые для
реплицированного основного датасета, и масштабируете систему по мере необхо-
димости для обработки текущего трафика. Схема Pilot light относительно проста
в реализации и недорогая. С другой стороны, в этом сценарии автоматический
запуск заменяющей системы занимает больше времени, что увеличивает RTO,
336
Глава 8. Факторы надежности архитектуры
a RPO в значительной мере зависит от типа репликации. Исследуем следующий
метод — теплый резерв, улучшающий RTO и RPO.
Теплый резерв (warm standby)
Теплый резерв, или полностью работоспособный резерв малой емкости, пред-
ставляет собой усовершенствованный метод DR, использующий гибкость
облачных платформ для предоставления экономичного решения. Этот метод
улучшает базовую стратегию Pilot light за счет поддержания подмножества
сервисов среды в постоянно рабочем состоянии, хотя и при меньшей емкости,
чем в полноценной рабочей среде.
Ключевым преимуществом стратегии теплого резерва является баланс между
экономией затрат и готовностью к восстановлению. Так как основные сервисы
уже работают, хотя и в меньшем масштабе, время восстановления в случае сбоя
значительно сокращается по сравнению со стратегиями холодного резерва или
запала, которые требуют выделения или масштабирования ресурсов в процессе
восстановления.
Организации могут настроить среды теплого резерва на обработку конкретного
процента рабочего трафика — например, 20,30 или 50 % в зависимости от целей
восстановления и бюджета. Такая гибкость позволяет создавать адаптирован-
ные DR-решения, которые сочетаются с потребностями бизнеса и уровнями
допустимости риска.
Заметим, что среда теплого резерва не ограничивается DR-сценариями — она
также может предоставлять платформу для служебных целей: тестирования,
промежуточного развертывания или разработки. Двойственная природа среды
теплого восстановления максимизирует ценность вложений в DR за счет воз-
можности использования инфраструктуры для дополнительных целей, помимо
простой готовности резерва. Таким образом, оптимизируются загрузка ресурсов
и эффективность затрат.
На рис. 8.7 изображены две системы, работающие в режиме теплого резерва
(центральная система и резерв низкой емкости) в облаке AWS. Для распреде-
ления запросов между центральной и облачной системами можно использовать
маршрутизатор — например, Amazon Route 53.
Применительно к базам данных теплый резерв действует примерно так же,
как и Pilot light, в котором данные непрерывно реплицируются с основной
площадки на DR-площадку. С другой стороны, в режиме теплого резерва все
необходимые компоненты работают в режиме 24/7, но не масштабируются для
рабочего трафика.
Выбор технологии для архитектурной надежности 337
J Локальное размещение
Веб-сервер
Сервер базы данных
Пользователь
Облако AWS
Amazon S3 Route 53
Hosted Zone
Зеркало/репликация данных
_L.Li._LL “
.....Г
Веб-сервер
inn.
ИНГ
Сервер приложения
Сервер базы данных
Рис. 8.7. Сценарий теплого резерва в режиме «активный/активный»
при низкой емкости
Часто организация выбирает стратегию теплого резерва для критически важ-
ных рабочих нагрузок, поэтому необходимо позаботиться о том, чтобы на DR-
площадке не возникало проблем; в этом вам поможет непрерывное тестирова-
ние. Лучше всего использовать А/В-тестирование, когда основная площадка
обрабатывает более значительный трафик. Небольшая доля трафика, примерно
от 1 до 5 %, направляется на DR-площадку. Это гарантирует, что она сможет
обрабатывать трафик даже при выходе из строя основной площадки. Также не
забудьте регулярно устанавливать патчи и обновления ПО на DR-площадке,
чтобы поддерживать ее синхронизацию с рабочей средой.
Как показано на рис. 8.8, во время недоступности основной среды маршрутизатор
переключается на вторичную систему, которая спроектирована для автоматиче-
ского масштабирования емкости в случае отработки отказа в основной системе.
338 Глава 8. Факторы надежности архитектуры
пгЛокальное размещение
Сервер базы данных
Amazon S3 Route 53
Hosted Zone
Облако AWS
> JJJJLU ---------
III г
Веб-сервер
• -
%гттГ
Сервер приложения
Зеркало/репликация данных
Сервер базы данных
Масштабирование до рабочей
емкости
Рис. 8.8. Фаза восстановления в сценарии теплого резерва
Представим, что сбой произошел на основной площадке. В таком случае не-
обходимо действовать по следующей схеме.
1. Немедленно перенесите трафик критически важной рабочей нагрузки на
DR-площадку, увеличив долю трафика вторичной площадки с 5 до 100 %.
Например, в сфере банкинга необходимо первым делом «поднять» сайт,
с которым работают клиенты, чтобы обеспечить его функционирование.
2. Масштабируйте среду, которая работала на низкой емкости. Для баз данных
можно применять вертикальное масштабирование, а для серверов — гори-
зонтальное.
3. Во время масштабирования среды займитесь переносом других некритиче-
ски важных рабочих нагрузок, работающих в фоновом режиме, — например,
управления складскими запасами и доставки.
Для реализации теплого резерва можно использовать такие инструменты,
как Terraform, — этот продукт с открытым исходным кодом, разработанный
HashiCorp, известен своей способностью безопасно и эффективно строить,
изменять и отслеживать версии инфраструктуры разных облачных провайде-
ров. На общем фоне Veeam выделяется полнофункциональными решениями
Выбор технологии для архитектурной надежности 339
резервного копирования и репликации, которые адаптируются для облачных,
виртуальных и физических сред, обеспечивая мощную поддержку мульти-
облачных стратегий. Zerto дополняет эту функциональность, предоставляя
средства аварийного восстановления, резервного копирования и мобильности
рабочей нагрузки, адаптированные для виртуализированных инфраструктур
и облачных сред.
Схема теплого резерва относительно сложна в реализации и затратна. Для
критической нагрузки время RTO намного меньше, чем у метода Pilot light.
С другой стороны, для некритических нагрузок оно зависит от того, насколько
быстро вы можете масштабировать систему, тогда как RPO в значительной мере
зависит от типа репликации. Рассмотрим следующий метод — горячий резерв,
для которого характерны почти нулевые значения RTO и RPO.
Горячий резерв
Наконец, стратегия горячего резерва помогает добиться почти нулевых значений
RTO и RPO. В этом методе DR-площадка служит репликой основной площадки
с непрерывной репликацией данных и потоком трафика между площадками.
Такая архитектура также называется распределенной (multi-site) из-за авто-
матизации распределения трафика между регионами или между локальной
и облачной средами.
Как показано на рис. 8.9, горячий резерв является следующим уровнем DR —
в облаке создается полностью функциональная система, которая существует
одновременно с локальными системами.
Преимущество стратегии горячего резерва заключается в том, что резервная
система в любой момент готова к принятию полной нагрузки режима реальной
эксплуатации. Это отчасти напоминает теплый резерв, но предполагает полную
емкость DR-площадки. Если основная площадка выходит из строя, весь трафик
может немедленно переключиться на аварийную площадку, что явно лучше
потери производительности и времени при переключении и масштабировании
площадки аварийного восстановления в случае теплого резерва.
Реализация DR-стратегии горячего резерва требует выбора современных ин-
струментов и технологий, спроектированных для автоматизации бесшовного
процесса обработки отказов и управления им, обеспечивая непрерывность экс-
плуатации с минимальными потерями производительности. Такие облачные
управляющие платформы, как vRealize Automation от VMware или Microsoft
Azure Site Recovery, играют ключевую роль в координации репликации вир-
туальных машин и данных, обеспечивая немедленное переключение на DR-
площадку при необходимости. Балансировщики нагрузки и глобальные системы
управления трафиком, включая такие решения, как F5BIG-IPn AWS Route 53,
динамически направляют трафик на основании доступности площадки и на-
грузки; таким образом гарантируется, что DR-площадка сможет мгновенно
обрабатывать входящие запросы.
340 Глава 8. Факторы надежности архитектуры
J Локальное размещение
Веб-сервер
Сервер приложения
Сервер базы данных
Пользователь
Amazon S3 Route 53
Hosted Zone
Зеркало/репликация данных
Сервер приложения
| Облако AWS
Веб-сервер
lifiii
*11 иг
Сервер базы данных
Рис. 8.9. Сценарий горячего резерва в режиме «активный/активный»
при полной емкости в AWS
Такие инструменты IaC (Infrastructure-as-Code), как Terraform и AWS
CloudFormation, позволяют оперативно предоставлять и масштабировать не-
обходимую инфраструктуру, чтобы DR-площадка быстро воспроизводила
функциональность рабочей среды. Кроме того, такие средства мониторинга
производительности сети, как SolarWinds и Nagios, предоставляют аналитику
работоспособности сети в реальном времени и позволяют быстро обнаруживать
проблемы, которые могут потребовать обработки отказа.
Схема горячего резерва — самая дорогостоящая из всех, так как она требует избы-
точности для всех компонентов. Тем не менее для бизнеса, требующего высокой
доступности и не допускающего простоев (например, финансовых учреждений,
организаций здравоохранения и платформ электронной коммерции), вложения
в реализацию горячего резерва могут быть оправданы тем, что удастся избежать
высоких потерь от потенциальных простоев.
В этом сценарии время RTO намного меньше для всех рабочих нагрузок, тогда
как RPO значительно зависит от типа репликации.
Рассмотрим некоторые лучшие DR-практики, которые обеспечивают надежную
работу системы.
Выбор технологии для архитектурной надежности 341
Применение лучших DR-практик
Планируя реализацию DR, необходимо учитывать ряд важных факторов.
• Начинайте с малого и добавляйте по мере необходимости: прежде всего
«оживляйте» критические рабочие нагрузки, оказывающие наибольшее
влияние на бизнес, и постепенно достраивайте решение, дополняя его менее
критически важными нагрузками.
• Применяйте жизненный цикл резервного копирования данных: создавайте
резервные копии всех данных, будь то файловый сервер, образ машины или
базы данных. Впрочем, хранение множества активных резервных копий может
повысить затраты, поэтому обязательно применяйте политику жизненного
цикла для архивации и удаления данных в соответствии с потребностями
бизнеса. Например, можно хранить активные резервные копии в течение
90 дней, а по истечении этого периода переносить их на более дешевые
архивные носители — например, на магнитные ленты или Amazon Glacier.
Через 1 или 2 года, согласно политике жизненного цикла, данные могут
быть удалены. Некоторые стандарты (такие, как PCI-DSS) могут требовать
хранения данных в течение 7 лет; в таком случае следует выбрать архивное
хранение для сокращения затрат.
• Проверяйте лицензии продуктов: управлять лицензиями может быть не-
просто, особенно в современной среде микросервисной архитектуры, где
несколько сервисов работают независимо на собственных виртуальных
машинах и базах данных. Лицензии могут быть привязаны к количеству
установок, процессоров и пользователей. Это может создать проблемы при
масштабировании. Важно отслеживать и проверять их; количество лицен-
зий должно быть достаточным для потребностей масштабирования. Также
постарайтесь не приобретать лишние лицензии — возможно, они останутся
неиспользованными, что приведет к лишним затратам. В целом лицензиями
следует управлять так же, как инфраструктурой или ПО.
• Планируйте масштабирование: для горизонтального масштабирования
добавьте дополнительные экземпляры с установленным ПО, а для верти-
кального — дополнительные процессоры или память. Необходимо понимать
условия лицензионных соглашений программных продуктов и следить, чтобы
лицензий было достаточно для масштабирования системы.
• Часто тестируйте свои решения: DR-площадки создаются на случай доволь-
но редких аварийных событий и поэтому часто остаются без внимания. Для
обеспечения высокой надежности в случае инцидента следите, чтобы решение
работало так, как задумано. Несоблюдение условий SLA может привести
к нарушению контрактных обязательств, потере денег и доверия клиентов.
• Проводите тренировочные дни: один из способов тестирования решений —
тренировочные дни. Выберите день, в который рабочая нагрузка невелика,
и соберите всю команду, ответственную за обслуживание рабочей сре-
ды. Смоделируйте происшествие: выведите из строя часть рабочей среды
342 Глава 8. Факторы надежности архитектуры
и посмотрите, как команда справляется с ситуацией, чтобы среда снова зара-
ботала. Такие мероприятия помогают убедиться в наличии работоспособных
резервных копий, снапшотов и образов машин для обработки аварийных
ситуаций.
• Проводите непрерывный мониторинг ресурсов: запустите систему монито-
ринга для автоматической обработки отказа и переключения на DR-площадку
в случае сбоя. Мониторинг помогает действовать проактивно, а отслеживание
емкости избавляет от проблемы с истощением ресурсов, которая может по-
влиять на надежность приложения.
Создайте DR-план и проводите регулярные проверки, чтобы обеспечить жела-
емую надежность приложения. В следующем разделе вы больше узнаете о по-
вышении надежности за счет использования публичных облачных платформ.
Повышение надежности в облаке
В предыдущих разделах мы приводили примеры облачной рабочей нагрузки
для DR-площадки. Многие организации начали выбирать облако в качестве
DR-площадки в целях повышения надежности приложения. Кроме того, об-
лачные предложения от основных провайдеров (таких, как AWS, Azure и GCP)
предлагают широкий диапазон сторонних решений, которые могут интегриро-
ваться в планирование и выполнение DR. Эти предложения обычно включают
инструменты резервного копирования и репликации, координации, мониторинга
и безопасности.
Облачная платформа предоставляет в ваше распоряжение дата-центры в раз-
ных географических областях. Можно без малейших усилий создать надежную
площадку на другом континенте. С облачными технологиями легко создавать
инфраструктуру (например, резервные копии и образы машин) и отслеживать
ее доступность.
В облаке простой мониторинг и отслеживание помогут обеспечить высокую
доступность приложения в соответствии с условиями SLA, определяемыми биз-
несом. Облако предоставляет детализированный контроль над ИТ-ресурсами,
затратами и компромиссами требований RPO/RTO.
Облачные платформы позволяют просто и эффективно протестировать DR-план.
Вы наследуете функциональность, доступную в облаке, — например, журналы
и метрики для различных облачных сервисов. Встроенные метрики становятся
мощным инструментом сбора информации о работоспособности системы.
Благодаря доступным средствам мониторинга легко оповещать команду о любых
нарушениях пороговых значений или запускать автоматизацию самовосстанов-
ления системы. Например, AWS предоставляет сервис Cloud Watch, который
собирает журналы и генерирует метрики одновременно с мониторингом разных
приложений и компонентов инфраструктуры. Он может инициировать запуск
автоматизированных процессов для масштабирования приложения.
Итоги 343
Облачная платформа предоставляет встроенный механизм управления измене-
ниями, который помогает отслеживать выделенные ресурсы. Облачные провай-
деры расширяют стандартные возможности, чтобы приложения и операционные
среды выполняли известный код и их можно было исправлять или заменять
контролируемым образом. Например, AWS предоставляет AWS Systems Manager
с функциональностью массовых патчей и обновлений облачных серверов.
Облачные платформы позволяют спроектировать масштабируемую систему
с необходимой гибкостью для автоматического добавления и удаления ресур-
сов в соответствии с текущими потребностями. Данные — один из важнейших
параметров надежности любого приложения. Облачные платформы предлагают
готовые средства резервного копирования и репликации данных, в том числе
образов машин, баз данных и файлов. В случае аварии в облаке будет своевре-
менно сохранена резервная копия всех данных, с помощью которой система
сможет быстро восстановиться.
Регулярное взаимодействие между командами разработки и эксплуатации по-
могает выявить и предотвратить проблемы и недочеты проектирования, тем
самым сокращая риск сбоев и отказов. Постоянно работайте над архитектурой
приложений, чтобы обеспечить ее устойчивость, и распределяйте приложения
для преодоления любых сбоев.
Итоги
В этой главе были рассмотрены различные принципы, обеспечивающие на-
дежность системы. К числу таких принципов относится возможность самовос-
становления системы путем применения правил автоматизации и сокращения
последствий сбоев за счет проектирования распределенных систем, в которых
рабочая нагрузка охватывает несколько ресурсов.
Общая надежность системы сильно зависит от ее доступности и способности вос-
станавливаться в аварийных ситуациях. Вы узнали о синхронной и асинхронной
репликации и о том, как она влияет на надежность систем. Вы изучили методы
репликации данных, включая репликацию на базе массивов хранения, сетевую
репликацию, репликацию на базе хоста и репликацию на базе гипервизора.
У каждого метода есть свои достоинства и недостатки. Компании-разработчики
предлагают разные продукты для репликации данных соответствующего типа.
Вы узнали о методах планирования аварийного восстановления (DR), зависящих
от потребностей организации и RTO/RPO. Мы рассмотрели метод резервного
копирования и восстановления, для которого характерны высокие значения
RTO/RPO и простота реализации. Метод Pilot light улучшает RTO/RPO за счет
поддержания критически важных ресурсов (например, баз данных) в активном
состоянии на DR-площадке. Методы теплого и горячего резерва поддерживают
активную копию рабочей нагрузки на DR-площадке и повышают надежность
приложения за счет снижения RTO/RPO, сложности и затрат системы.
344 Глава 8. Факторы надежности архитектуры
В завершение главы мы обсудили встроенные облачные средства, помогающие
повысить надежность приложения.
Проектирование и запуск решения выполняются время от времени, а обслужи-
вание (поддержка) — всегда. В следующей главе вы узнаете о таких параметрах
архитектуры решений, как оповещения и мониторинг, в том числе о принципах
их проектирования и выборе технологий, обеспечивающих операционную эф-
фективность приложения и операционное совершенство.
ГЛАВА 9
ОПЕРАЦИОННОЕ
СОВЕРШЕНСТВО
Поддерживаемость (maintainability) приложения — одно из главных условий,
которые должен учитывать архитектор решения в процессе проектирования
архитектуры. Каждый новый проект начинается с большого объема планиро-
вания и выделения первичных ресурсов, а команды первые месяцы проводят за
созданием и запуском приложений. После запуска рабочей версии необходимо
выполнять служебные операции, чтобы приложение продолжало успешно рабо-
тать. Необходимо постоянно отслеживать работу приложения, чтобы находить
и устранять любые текущие проблемы.
Команда эксплуатации должна решать все проблемы инфраструктуры, безопас-
ности и программного обеспечения, чтобы приложение продолжало надежно
работать. Обычно корпоративные приложения довольно сложны, и в них опре-
деляются условия соглашения об уровне обслуживания (SLA), относящиеся
к доступности. Команда эксплуатации должна понимать требования бизнеса
и быть готовой отреагировать на любую внештатную ситуацию.
Операционное совершенство (operational excellence) — это обеспечение эф-
фективной работы каждого компонента и уровня системной архитектуры. Оно
подразумевает непрерывный мониторинг, оптимизацию и улучшение процессов,
систем и сервисов.
Операционное совершенство должно охватывать все компоненты и уровни
архитектуры. В современных микросервисных приложениях задействовано
столько подвижных частей, что эксплуатация и поддержка системы становятся
достаточно сложной задачей.
Эксплуатационная команда должна внедрить необходимые механизмы монито-
ринга и оповещений, чтобы справиться с любыми проблемами, препятствующими
нормальной работе в режиме эксплуатации. Подготовка к решению проблем
в этой области обычно требует координации нескольких команд.
В этой главе вы изучите принципы проектирования, применимые для достиже-
ния операционного совершенства вашего решения. Вы поймете, как правильно
346
Глава 9. Операционное совершенство
выбирать технологии, обеспечивающие удобство обслуживания на каждом
уровне приложения. Мы разберем следующие лучшие практики операционного
совершенства:
• принципы проектирования для операционного совершенства;
• выбор технологий для операционного совершенства;
• достижение операционного совершенства на публичных облачных плат-
формах;
• повышение эффективности с помощью CloudOps.
К концу главы вы будете знать различные процессы и методы достижения
операционного совершенства. Вы узнаете о лучших практиках, применяемых
в процессе проектирования, реализации и последующей поддержки прило-
жения.
Принципы проектирования для операционного
совершенства
Операционное совершенство — это обеспечение бесперебойной работы приложе-
ния для получения максимальной бизнес-выгоды. Это подразумевает постоянное
внедрение улучшений, повышающих эффективность системы.
Ниже мы рассмотрим стандартные принципы проектирования, которые помогут
повысить удобство обслуживания системы. Вы увидите, что все принципы про-
ектирования операционного совершенства тесно связаны и дополняют друг друга.
Автоматизация ручных задач
Технологии стремительно развиваются, и ИТ-операции не должны отставать
от них — особенно там, где необходимое оборудование и программные продук-
ты поставляют несколько вендоров. Корпорации строят гибридные облачные
и мультиоблачные системы, поэтому следует освоить операции как в локальных,
так и в облачных средах. Современные системы имеют обширные пользователь-
ские базы, в них задействованы различные микросервисы и миллионы устройств,
объединенных в сеть. ИТ-операции включают множество изменяющихся ком-
понентов, из-за чего их трудно выполнять вручную.
Организации стремятся к гибкости, и эксплуатационная команда должна
действовать быстро, чтобы обеспечивать необходимую инфраструктуру для
разработки и развертывания новых сервисов. У нее есть и еще более серьезная
задача — поддерживать бесперебойную работу сервисов и оперативно восстанав-
ливать их в случае нештатных ситуаций. ИТ-операции требуют проактивного
подхода, а не ожидания инцидента и последующего реагирования.
Команда эксплуатации может работать очень эффективно, применяя авто-
матизацию. Ручные задачи должны быть автоматизированы, чтобы команда
могла сосредоточиться на стратегических инициативах и не тратить время на
Принципы проектирования для операционного совершенства 347
тактическую работу. Для разгрузки людей чрезвычайно важно автоматизировать
обнаружение любых угроз безопасности и реагирование на них. Запуск нового
сервера или запуск/остановка сервисов должны автоматизироваться с исполь-
зованием подхода «инфраструктура как код» (1аС). Автоматизация позволяет
команде уделять больше времени инновациям.
Используя прогнозные методы машинного обучения, в веб-приложениях можно
обнаруживать аномалии прежде, чем они повлияют на систему. Например, можно
создать автоматическое уведомление безопасности на случай, если кто-то от-
кроет доступ к вашему серверу через НТТР-порт 80. Почти всю инфраструктуру
можно автоматизировать и заново развернуть ее одним кликом. Автоматизация
также помогает предотвращать человеческие ошибки, которые происходят
даже в том случае, если человек постоянно выполняет одну и ту же работу. Для
ИТ-операций автоматизация стала практически обязательной.
Инкрементные и обратимые изменения
Оптимизация операций — текущий процесс, а выявление недостатков и их
исправление требуют непрерывных усилий. Эти усилия могут быть сосредо-
точены на надежности, доступности, производительности и экономической
эффективности. Это гарантия того, что архитектура соответствует бизнес-целям
и адаптируется к изменяющимся потребностям. Обеспечение операционного
совершенства — это постоянный процесс. Он требует регулярных изменений
во всех частях рабочей нагрузки. Например, серверные операционные системы
обычно необходимо обновлять патчами безопасности, предоставляемыми ком-
панией-разработчиком. Также требуется обновлять версии программ, исполь-
зуемых приложением. Бывает, что приходится вносить изменения в систему
для соответствия новым нормативным требованиям.
Проектируйте рабочую нагрузку так, чтобы все компоненты системы можно было
регулярно обновлять, а система получала преимущество благодаря новейшим
и важным обновлениям. Автоматизируйте рабочие процессы и применяйте
в них небольшие инкрементные изменения, чтобы избежать значительных по-
следствий. Все изменения должны быть обратимыми, чтобы при возникновении
проблем можно было восстановить рабочее состояние системы. Инкрементные
изменения упрощают тщательное тестирование и улучшают общую надежность
системы. Автоматизируйте все управление изменениями, чтобы избежать чело-
веческих ошибок и обеспечить эффективность.
Прогнозирование сбоев и реагирование
Предотвращение сбоев крайне важно для достижения операционного совершен-
ства. Сбои неизбежны, и очень важно выявить как их как можно раньше. В про-
цессе проектирования архитектуры учитывайте возможность сбоев и заложите ее
в дизайн, чтобы предотвратить их возникновение. Исходите из предположения,
348 Глава 9. Операционное совершенство
что сбои будут везде и всегда, и подготовьте план резервного восстановления.
Проводите регулярные тренировки, чтобы выявить любые потенциальные ис-
точники сбоев. Попробуйте исключить или минимизировать любые ресурсы,
которые могут стать причиной сбоев во время работы системы.
Создайте на основании SLA тестовый сценарий, включающий целевое время
восстановления (RTO) и целевую точку восстановления (RPO) системы. Про-
тестируйте сценарий и убедитесь, что понимаете все последствия его реализации.
Убедитесь, что команда готова отреагировать на любой инцидент, смоделировав
условия, близкие к реальным. Протестируйте процедуру реагирования и проверь-
те, что команда эффективно справляется с проблемами. Сформируйте команду,
уверенную в своих силах и знакомую с процедурой реагирования.
Анализ ошибок и выводы
При возникновении операционных сбоев в системе следует учиться на своих
ошибках и выявлять причины произошедшего. Позаботьтесь, чтобы случившиеся
события не повторялись, и приготовьте решение на случай повторения сбоя.
Один из способов, как это сделать, основан на анализе первопричин (RCA,
Root Cause Analysis). В процессе RCA вы собираете команду и задаете пять
вопросов «почему». С каждым вопросом выявляется очередной уровень про-
блемы, и после последнего вопроса вы добираетесь до первопричин. После
определения настоящей причины проблемы можно подготовить решение
и обновить инструкции.
Так как рабочая нагрузка будет изменяться со временем, необходимо позабо-
титься о соответствующем изменении операционных процедур. Обязательно
регулярно проверяйте и тестируйте все процедуры, чтобы команда была знакома
с последними обновлениями и выполняла их.
Актуализация ран бука
Зачастую команды пренебрегают документированием, и ранбук (операционная
документация) устаревает. В ранбуке приводятся рекомендации по разрешению
проблем, возникающих из-за внешних или внутренних событий. В отсутствие
актуальной документации операции начинают зависеть от человеческого факто-
ра, что может быть рискованно из-за текучки сотрудников. Всегда определяйте
процессы так, чтобы системные операции не зависели от людей, и документи-
руйте всё.
В ранбуке следует фиксировать все предшествующие события и меры, принятые
для решения проблемы, чтобы новые члены команды могли быстро разрешать
похожие инциденты в ходе поддержки операций.
Системный администратор должен следить за состоянием ранбука, чтобы он
содержал описание этапов запуска, остановки, установки исправлений и об-
новлений системы. Команда эксплуатации должна включить в него результаты
Выбор технологий для операционного совершенства 349
тестирования и проверки системы, а также описание процедуры реагирования
на событие. В ранбук также должны войти SLA, установленные в отношении
RTO/RPO, задержки, масштабируемости, производительности и т. д.
Автоматизируйте процессы аннотирования документации при внесении измене-
ний в систему, а также после каждой сборки. Аннотации могут использоваться
для автоматизации операций, и их легко читать на программном уровне, чтобы
постоянно учитывать приоритеты бизнеса и потребности клиентов.
Выбор технологий для операционного
совершенства
Эксплуатационной команде необходимо разработать процедуры и шаги для
разрешения любых инцидентов и подтверждения эффективности своих дей-
ствий. Команда должна понимать потребности бизнеса, чтобы обеспечивать
качественную поддержку, а также собирать системные и бизнес-метрики для
оценки результатов.
Операции можно разделить на три этапа — планирование, функционирование
и усовершенствование. Давайте рассмотрим технологии, которые можно ис-
пользовать на каждом из них.
Планирование операционного совершенства
Первый шаг — определить приоритеты, сосредоточившись на областях со зна-
чительным влиянием на бизнес. Такими областями могут быть автоматизация,
оптимизация мониторинга, развитие навыков команды в соответствии с изме-
няющейся рабочей нагрузкой, а также повышение общей производительности
системы.
Существуют различные инструменты и сервисы, которые в фоновом режиме
анализируют систему, сканируя ее журналы и активность. Эти инструменты
предоставляют фундаментальный набор оценок. Оценки помогают определить
приоритеты, предоставляя ключевую информацию о системе и рекомендации
для оптимизации.
После выявления и расстановки приоритетов необходимо спроектировать
операции, в частности рабочие нагрузки и процедуры их поддержки. Проекти-
рование рабочей нагрузки должно охватывать ее реализацию, развертывание,
процесс обновления и стратегию эксплуатации. Вся рабочая нагрузка может
рассматриваться как совокупность компонентов приложения, инфраструктуры,
безопасности, управления данными и автоматизации операций. Завершив про-
ектирование операций, создайте чек-лист для проверки операционной готов-
ности. Чек-листы должны быть всеобъемлющими для обеспечения готовности
к выполнению текущих операций, когда приложение будет выпущено на про-
дакшен. К таким операциям относятся ведение журналов и мониторинг, план
350 Глава 9. Операционное совершенство
коммуникации, механизм оповещений, повышение квалификации команды,
план поддержки, механизм поддержки со стороны поставщиков и т. д.
Вот две области планирования операционного совершенства, в которых пона-
добятся соответствующие средства подготовки:
• управление ИТ-активами (ИТ-ресурсами);
• управление конфигурацией.
Рассмотрим эти области более подробно, чтобы понять, какие инструменты
и процессы для них доступны.
Управление ИТ-активами
Планирование операционного совершенства требует учета ИТ-ресурсов и кон-
троля их использования. К таким ресурсам относятся:
• инфраструктурное оборудование (физические серверы, сетевые устройства,
системы хранения, устройства конечных пользователей и т. д.);
• программное обеспечение (лицензии программных продуктов, операционные
данные);
• юридические аспекты (контракты, соответствие нормативно-правовым
требованиям).
Другими словами, это все системы, оборудование и информация, используемые
компанией для ведения бизнеса.
Отслеживание ИТ-активов помогает организациям принимать стратегические
и тактические решения, относящиеся к поддержке и планированию операций.
Однако управлять ИТ-активами в большой организации может быть непросто.
Существуют различные инструменты управления ИТ-активами (ITAM, IT
Asset Management), которые упрощают этот процесс. Среди самых популярных
инструментов IT AM можно выделить SolarWinds, Freshservice, ServiceDesk
Plus, Asset Panda, PagerDuty и Jira Service Desk.
Управление ИТ-ресурсами не ограничивается их отслеживанием. Оно подразумева-
ет также непрерывный мониторинг и сбор данных для оптимизации использования
ресурсов и эксплуатационных затрат. IT AM значительно повышает адаптивность
организаций, предоставляя сквозную видимость и возможность быстрой установки
обновлений и исправлений. Схема ITAM представлена на рис. 9.1.
Как показано на диаграмме, процесс ITAM включает следующие этапы.
• Планирование: жизненный цикл актива начинается с планирования — стра-
тегического анализа для определения необходимости в ИТ-активах и методах
их приобретения. Планирование включает оценку экономической выгоды
и расчет совокупной стоимости владения (ТСО).
• Приобретение: организация приобретает активы на основании результатов
планирования. Она также может выбрать самостоятельную разработку
Выбор технологий для операционного совершенства 351
некоторых компонентов — например, собственного ПО для ведения журна-
лов и мониторинга.
• Интеграция: актив внедряется в ИТ-экосистему. Этот этап включает на-
стройку работы и поддержку актива, в том числе определение прав доступа
пользователей — например, установку агента, который собирает данные
журналов со всех серверов в централизованном дашборде, и ограничение
отслеживания метрик в дашборде только командой эксплуатации.
• Обслуживание: команда эксплуатации отслеживает ресурсы и принима-
ет меры для их обновления или миграции на основании их жизненного
цикла — например, установку патчей безопасности, предоставляемых
разработчиком ПО. Для этого необходимо отслеживать срок жизни ли-
цензируемого ПО (например, запланировать миграцию с Windows Server
2008 на Windows 2022, так как старая операционная система скоро пере-
станет поддерживаться).
• Списание: на этапе списания команда эксплуатации избавляется от ресурсов
с истекшим сроком жизни. Например, если срок жизни сервера базы данных
подходит к концу, команда принимает меры по его замене и миграции не-
обходимых пользователей и поддержки на новый сервер.
Рис. 9.1. Процесс ITAM
352 Глава 9. Операционное совершенство
IT AM помогает организациям соблюдать требования к соответствию стандарту
ISO 19770. Процедура предусматривает этапы приобретения ПО, развертыва-
ния, обновления и поддержки. IT AM обеспечивает повышенную безопасность
данных и соответствие нормативам в этой области. Кроме того, IT AM улучшает
коммуникации между подразделениями — например, командами эксплуатации,
финансов, маркетинга и клиентской поддержки.
Управление конфигурацией — еще один важный аспект планирования опера-
ционного совершенства, который помогает поддерживать актуальные данные
об ИТ-активах, включая информацию о владельце и текущем состоянии. Рас-
смотрим эту тему более подробно.
Управление конфигурацией
Управление конфигурацией обеспечивает обслуживание элементов конфи-
гурации (Cis, Configuration Items) и предоставление ИТ-сервиса. Элементы
конфигурации хранятся в базе данных управления конфигурацией (CMDB,
Configuration Management DataBase). В CMDB содержится информация о том,
является сервер физическим или виртуальным, об операционной системе и ее
версии (например, Windows 2022 или Red Hat Enterprise Linux 8.0), владель-
це сервера (например, команда поддержки, или маркетинга, или управления
персоналом), а также о наличии зависимостей от других серверов (например,
управления заказами) и т. д.
Управление конфигурацией отличается от управления ресурсами. Управление
ресурсами распространяется на весь жизненный цикл ресурса, от планирования
до списания, тогда как CMDB — компонент управления ресурсами, в котором
хранятся записи конфигурации отдельных ресурсов. Как показано на рис. 9.2,
управление конфигурацией реализует часть управления ресурсами, связанную
с интеграцией и обслуживанием.
Управление конфигурацией и управление изменениями-взаимодополняющие
процессы ИТ-операций. Управление конфигурации сосредоточено на
поддержании точной и актуальной информации обо всех компонентах в ИТ-
среде организации, включая их версии, конфигурации и взаимосвязи. Тем
самым гарантируется последовательное и эффективное развертывание
и деятельность систем. Управление изменениями означает отслеживание
и управление изменениями в ИТ-инфраструктуре, гарантируя, что изменения
будут реализованы скоординированно и системно, чтобы избежать
непредвиденных последствий. Вместе они помогают поддерживать
целостность и стабильность ИТ-ресурсов, при этом управление конфигурацией
предоставляет подробную информацию, необходимую для оценки влияния
изменений, а управление изменениями гарантирует, что все изменения
в конфигурациях будут должным образом спланированы, выполнены
и задокументированы.
Выбор технологий для операционного совершенства 353
Управление
конфигурацией
Рис. 9.2. Жизненный цикл ИТ-ресурса и управление конфигурацией
Средства управления конфигурацией могут помочь команде эксплуатации со-
кратить время неработоспособности за счет представления доступной инфор-
мации о конфигурации ресурсов. Самые популярные инструменты управления
конфигурацией — Chef, Puppet, Ansible и Bamboo. Более подробная информа-
ция о них будет представлена в главе 11 «DevOps и фреймворк архитектуры
решений».
Управление ИТ-средой упрощается, если рабочая нагрузка находится на пуб-
личной облачной платформе — такой, как AWS, Microsoft Azure или GCP. Об-
лачные провайдеры предоставляют встроенные инструменты для отслеживания
и управления ИТ-активами и их конфигурациями в одном месте. Например,
у AWS есть сервис AWS Config, который отслеживает все ИТ-ресурсы, запускае-
мые как часть рабочей нагрузки в облаке AWS, и сервис AWS Trusted Advisor,
рекомендующий те способы оптимизации затрат, производительности и безопас-
ности, что могут использоваться для принятия решений об управлении рабочей
нагрузкой. Пример использования AWS Trusted Advisor представлен на рис. 9.3.
354
Глава 9. Операционное совершенство
Trusted Advisor Recommendations
©о
$40.55
Гмм«««г bw к*WK и—МЫМСРН*
гвиммт (ЧгомЛ мвМтмсмйгмАй
RKMdMfl$«l (11)
•М Мм»1 МВ Очн» »4ма1 чч И И»»»«Ы1М
С*.
•Ь WBM
К’чдаи
•WWKJ1
ВДНЛ«1
Рис. 9.3. Дашборд AWS Trusted Advisor
Как показано на снимке, AWS Trusted Advisor находит 12 проблем с безопас-
ностью, которые можно дополнительно исследовать для получения более под-
робной информации.
Управление конфигурацией играет ключевую роль в непрерывном мониторинге
и документировании конфигураций ИТ-ресурсов. Оно позволяет автоматизиро-
вать оценку конфигураций по заранее определенным стандартам. Перечислим
некоторые преимущества управления конфигурацией.
• Непрерывный мониторинг делает возможным текущее наблюдение и до-
кументирование изменений в конфигурациях ИТ-ресурсов.
• Управление изменениями помогает отслеживать взаимосвязи между
ресурсами и анализировать зависимости перед реализациями любых из-
менений.
• Непрерывная оценка упрощает регулярный аудит и проверки того, что
ИТ-ресурсы соответствуют политикам и рекомендациям организации.
• Мониторинг соответствия в масштабах организации дает комплексное
представление о статусе соответствия нормативам в масштабах организации,
выявляет все несоответствия и позволяет проводить углубленный анализ на
региональном уровне.
• Управление сторонними ресурсами позволяет документировать конфигу-
рации для сторонних ресурсов: репозиториев GitHub, ресурсов Microsoft
Active Directory и серверов (как локальных, так и находящихся в облаке).
• Операционная диагностика сохраняет подробную историю изменений кон-
фигурации, что упрощает разрешение эксплуатационных проблем.
Выбор технологий для операционного совершенства 355
Управление конфигурацией дает возможность проведения анализа безопас-
ности, непрерывного наблюдения за конфигурациями ресурсов и оценки этих
конфигураций на предмет потенциальных уязвимостей безопасности. Оно
играет важную роль обеспечении соблюдения внутренних политик и норма-
тивных стандартов в конфигурациях ИТ-ресурсов (как внутри организации,
так и внешних) и непрерывном анализе изменений конфигурации ресурсов
относительно желаемых стандартов.
В этом разделе вы узнали об управлении ресурсами и конфигурациями. Они
являются частью фреймворка ITIL (Information Technology Infrastructure
Library), реализующего набор процессов ITSM (Information Technology Service
Management), актуальный для операционной эффективности. ITSM помогает
организациям в ежедневном ведении ИТ-операций. Узнать больше об ITIL
можно на сайте его руководящего органа, AXELOS (https://www.axelos.com/best-
practice-solutions/itil). AXELOS предлагает сертификацию ITIL для повышения
квалификации в процессе управления ИТ-сервисами.
После знакомства с планированием перейдем к рассмотрению функциониро-
вания ИТ-операций.
Достижение операционного совершенства
Операционное совершенство достигается путем проактивного мониторинга
и скоростью реагирования и восстановления в случае нештатных ситуаций. По-
нимая состояние рабочей нагрузки, можно определить, как события и реакции
на них влияют на ее работоспособность. Используйте инструменты, которые
помогают оценить состояние системы при помощи метрик и дашбордов. От-
правляйте данные журналов в централизованное хранилище и определяйте ме-
трики для определения эталонных значений. Эти инструменты также позволяют
автоматизировать реакцию на события и инициировать их выполнение в ответ
на конкретные оповещения.
Проектируйте компоненты рабочей нагрузки так, чтобы они были заменяемыми.
Это позволит не тратить время на решение проблем, а сокращать срок
восстановления заменой неработоспособных компонентов надежными,
известными версиями. Затем можно проанализировать неработоспособные
ресурсы, не затрагивая продакшен-среду.
Для достижения операционного совершенства вам понадобятся специальные
инструменты в следующих областях:
• мониторинг работоспособности системы;
• обработка оповещений (алертов) и реагирование на инциденты.
Рассмотрим эти области и доступные для них инструменты и процессы.
356
Глава 9. Операционное совершенство
Мониторинг работоспособности системы
Отслеживание работоспособности системы абсолютно необходимо для понима-
ния поведения рабочей нагрузки. Команда эксплуатации использует мониторинг
работоспособности системы для регистрации любых аномалий в компонентах
системы и выполнения соответствующих действий.
Традиционно мониторинг ограничивается уровнем инфраструктуры, отсле-
живанием загруженности памяти и процессоров на серверах. Однако его необ-
ходимо проводить на каждом уровне архитектуры. Важнейшие части системы,
требующие мониторинга:
• инфраструктура;
• приложения;
• платформа;
• журналы;
• безопасность.
Мониторинг этих компонентов рассматривается в следующих подразделах.
Мониторинг инфраструктуры
Мониторинг инфраструктуры чрезвычайно важен, и это самая востребованная
разновидность мониторинга. Инфраструктура включает компоненты, необхо-
димые для хостинга приложений. К ней относятся такие базовые сервисы, как
хранение данных, серверы, сетевой трафик, балансировщики нагрузки и т. д.
Мониторинг инфраструктуры может включать следующие метрики.
• Загруженность процессора: процент использования ЦП сервером за опре-
деленный период.
• Загруженность памяти: процент оперативной памяти (ОЗУ, или RAM),
используемой сервером за определенный период.
• Использование сети: количество входящих и исходящих пакетов за опре-
деленный период.
• Использование диска: пропускная способность диска для чтения/записи
и количество операций ввода/вывода в секунду (IOPS).
• Балансировщик нагрузки: счетчики количества запросов за определенный
период.
Существуют и другие метрики; организации должны настраивать их в соответ-
ствии с особенностями приложения. На рис. 9.4 показан пример дашборда для
мониторинга сетевого трафика.
Выбор технологий для операционного совершенства 357
Из снимка экрана видно, что в один день наблюдался выброс на панели среднего
входящего сетевого трафика (Network In Average), с цветовым кодированием
разных серверов. Команда эксплуатации может тщательно изучить этот и другие
графики и ресурсы, чтобы получить более детализированное понимание общей
работоспособности инфраструктуры.
Disk Witte Ops Average
t>j k “.V fa Brte4; Average
vetwoiк ОИ Average
Nework Id Average
• M1O4M8IFJJJH_
• КЗ
• kOMMttIMFdl..
• K2
Network Pockets (n Average
Рис. 9.4. Дашборд мониторинга сетевого трафика
Network Packets Out Average
Мониторинг приложения
Иногда инфраструктура полностью работоспособна, но в приложениях возникает
проблема, обусловленная ошибкой в коде или стороннем ПО. Возможно, вы
установили патч безопасности для операционной системы, предоставленный вен-
дором, и это нарушило работу системы. Мониторинг поможет решить проблему.
Мониторинг приложения может включать следующие метрики.
• Вызовы эндпоинта: количество запросов за заданный период.
• Время отклика: среднее время отклика на запрос.
• Троттлинг: количество валидных запросов, отклоненных из-за того, что
система не может справиться с дополнительной нагрузкой.
• Ошибки: сбои при обработке запросов.
На рис. 9.5 представлен дашборд с данными мониторинга эндпоинта некоторого
приложения.
358 Глава 9. Операционное совершенство
Invocadctrc Sum
ОКИ С4Л1 Ш1 СТО
• cab-Mt*
• Ь'кОДмш'М»
кк^мМ^ояййИйК-С^
• mq
CABRiriDvw4iv4Ata<v,
J№»ttllfWu-CodlO<toLk
Duration Average
UMtaemd*
suit t :
ieu
MjT _.i—.-<,—. ,..
0И4 04/11 Wit 0№2S
Throttles Sjm
• otMUI
9 book'trbHwwMfr
® шин pytwjft
H-rtWCotffckWC
Ф hn-wt-go-qgiM
• «Q
СМПп^Оето-С-чИОоМвгч.
йА ^HU^wn^CWiBt Jf).
Errors Sum
сын
04*04 «Л1 W14 №»
(jOHt
t •«злглсмгенлавикю..
• ОШШОапй4й0№№._
th» и4 J
flj <СЛД|Й
Рис. 9.5. Дашборд мониторинга приложения
Можно использовать и другие метрики в зависимости от приложения
и технологии — например, затраты памяти на сборку мусора для приложе-
ний Java, примеры запросов HTTP POST и GET для сервиса RESTful, счетчик
клиентских ошибок 4ХХ, счетчик серверных ошибок 5ХХ для веб-приложения
и любые другие, которые могут указывать на плохую работоспособность при-
ложения.
Мониторинг платформы
Приложение может использовать разные сторонние платформы и инструменты,
для которых необходимо проводить мониторинг. К числу таких инструментов
относятся:
• кэширование памяти: Redis и Memcached;
• реляционная база данных: Oracle Database, Microsoft SQL Server, Amazon
Relational Database Service (RDS), PostgreSQL;
• база данных NoSQL: Amazon DynamoDB, Apache Cassandra, MongoDB;
• платформа больших данных: Apache Hadoop, Apache Spark, Apache Hive,
Apache Impala, Amazon Elastic MapReduce (EMR);
• контейнеры: Docker, Kubernetes, OpenShift;
• средства бизнес-анализа: Tableau, MicroStrategy, Kibana, Amazon QuickSight;
• система обмена сообщениями: MQSeries, Java Message Service (JMS),
RabbitMQ, Simple Queue Service (SQS);
• поиск: OpenSearch, приложение на базе Solr.
Каждый из инструментов, упомянутых выше, имеет собственный набор метрик,
которые необходимо отслеживать, чтобы гарантировать работоспособность
всего приложения. На рис. 9.6 представлен дашборд мониторинга платформы
для реляционной базы данных.
Выбор технологий для операционного совершенства 359
Reea JOr*S Aveлвде
Read Latency Average
ЗфсапЛ
Read Throughput Average
EVW5fcc»e
-iJ3
Рис. 9.6. Дашборд мониторинга платформы для реляционной базы данных
Write ЮР
0И1 0ШЛ U»I
• ( НнГМщл
Из этого дашборда видно, что база данных выполняет большой объем опе-
раций записи, то есть приложение постоянно записывает данные. С другой
стороны, операции чтения относительно стабильны, если не считать несколь-
ких пиков.
Мониторинг журналов
Традиционно мониторинг журналов проводился вручную. Организации только
реагировали на происходящее и переходили к анализу журналов при обнаруже-
нии ошибок. Однако с усилением конкуренции и повышением пользовательских
ожиданий возникла необходимость быстро принимать меры еще до того, как
пользователь заметил проблему. Чтобы действовать проактивно, необходимо
иметь возможность пересылать журналы в централизованное хранилище и вы-
полнять запросы для мониторинга и выявления проблем. Например, если стра-
ница какого-то товара выдает ошибку, необходимо немедленно ее распознать
и исправить до того, как пользователи начнут жаловаться; в противном случае
вы рискуете потерять деньги.
В случае любых сетевых атак необходимо проанализировать сетевой журнал
и заблокировать подозрительные IP-адреса. Эти IP-адреса могут отправлять
аномальное количество пакетов данных, чтобы нарушить работу приложения.
Такие системы мониторинга, как AWS Cloud Watch, Logstash, Splunk, Google
Stackdriver и др., предоставляют агент, который необходимо установить на сер-
вере приложения. Агент пересылает журналы в централизованное хранилище.
Можно напрямую обращаться с запросами к централизованному хранилищу
журналов и включать оповещения о любых аномалиях.
На рис. 9.7 представлен пример сетевого журнала, находящегося в централизо-
ванном хранилище.
360 Глава 9. Операционное совершенство
2 789211807855 eni-0c7812c5SS22bdM7 172.31.0.23 172.31. fl. 252 49232 1433 G 40 I860 1549397294 1549397893 ACCENT OK
2 789211807855 eni-ec£918ddd57F2978f 184.248.247.73 172.31.0.202 33794 8ЙЙ8 6 1 40 1549397503 1549397563 REJECT OK
2 789211807855 eni-ecG9L&Md57F29W 78 .126.112.98 17231.0.202 58594 3393 6 1 40 1549397503 15^9(397563 REJECT OK
2 789211807855 cnl-0cG910ddd57f2978f 172Л0+.121.2М 172.31.6,202 38620 465 6 1 40 1549397500 1549397563 REJECT OK
2 789211807855 eniec691W*J57F297Sf 193,32.160,35 172.31.0.202 48479 40004 6 1 40 1549397503 1549397563 REJECT OK
2 789211807855 efti-0c6fll8dMS7f2978F 172.31.0.202 172.31.0.23 46316 1433 6 20 1280 1540397563 1549398103 ACCEPT OK
2 789211807855 eni-0c69LWddS7fa978f 172,31.0.23 172.31,0,202 1433 46346 0 20 820 1549397503 1549398103 ACCEPT OK
2 789211807855 •nt-0e69l&Md57f2978F 172 310 702 172.91.0.21 44022 1433 5 20 1280 3549397503 1540398103 ACCEPT OK
Рис. 9.7. Неформатированные данные журнала, переданные
в централизованное хранилище данных
Например, можно выполнить запрос к журналам и узнать top-10 IP-адресов
с наибольшим количеством отклоненных запросов (рис. 9.8).
Как видно из скриншота редактора запросов, можно построить график и вклю-
чить оповещение при превышении определенного порога отклоненных запро-
сов — например, 5000.
Мониторинг безопасности
Безопасность — важнейшая характеристика любого приложения. При проекти-
ровании решений необходимо предусмотреть мониторинг безопасности. Как вы
узнали из главы 7 «Факторы безопасности», безопасность должна реализовы-
ваться на всех уровнях. Рекомендуется реализовать мониторинг безопасности
так, чтобы активно реагировать на любые нежелательные события.
Ниже перечислены уровни, на которых должен осуществляться мониторинг
безопасности.
• Сетевая безопасность: мониторинг любых несанкционированных открытий
портов, подозрительных IP-адресов и активности.
• Пользовательский доступ: мониторинг любых несанкционированных поль-
зовательских обращений и подозрительной пользовательской активности.
• Безопасность приложений: мониторинг для выявления вредоносного ПО
и вирусных атак.
• Веб-безопасность: мониторинг для выявления DDoS-атак, внедрения SQL-
инъекций и межсайтовых скриптовых атак (XSS).
• Безопасность сервера: мониторинг любых пропусков в установке патчей
безопасности.
Выбор технологий для операционного совершенства 361
• Комплаенс: выявление любые нарушений, например проверка соответствия
PCI (Payment Card Industry) для платежных приложений или соответствия
HIPAA (Health Insurance Portability and Accountability Act) для приложений
из области здравоохранения.
• Безопасность данных: мониторинг несанкционированных обращений
к данным, маскирования данных и шифрования данных при хранении
и передаче.
filter action-"REJECT* I stats count(*) as nurtejections
by srcAddr 1 sort numRejections desc I Halt 19
Run query
Actions v
Sample queries
Have
feedback? Email tis.
Logs Visualization
110,245 records matched 1110,266 records (15.2 MB) scanned in
6.1s @ 17,958 records/s (2.5 MB/s)
f : srcAddr = nunRejections
1 80.82.78.104 2414
2 167.71.184.66 2223
3 185.176.27.170 1749
4 159.65.25.220 1556
5 104.199.19.160 1443
6 167.99.138.184 959
7 167.71.62.190 914
8 162.220.166.114 914
9 66.23.231.121 869
10 51.83.69.99 846
Рис. 9.8. Информация, полученная в результате выполнения запроса
к сетевому журналу
Пример мониторинга безопасности с использованием Amazon GuardDuty для
облачной платформы AWS представлен на рис. 9.9.
362 Глава 9. Операционное совершенство
Gu/rdPuly X
s*tur^t
um
nq
{MW
Nrtiwd □
Findings 0
A«Xffl т
Afftiht
Mil.
U'fcih<
wmeH*;
— nr
Sbowtat306432 ООО
j Sn^fiCCK/AutMKNH Apffy fowl tutrn
7 [ • Jwnty.MHl wry H>?h <Э] ЛйУЙГгрcrtur*
—
Adffl*KASIA2221WMXXWG5^rN8 l»hMrs«
□ □ unwthodndActKbiAMibM/CfifiwtaAgta Mm*
; □ I4»«CQMKMvWnvflk
№МСЕ KH41 №73Г1Ы№1
$*ч/№ X
Att4T Банк r
742577в.„ )
*»ь>нл^ > 1
□ □ n?jma/w«4<iTrjin{
□ □ RCWKUMUW7TH9Q4IV
□ □ ипшьмммстмммагполкжг
□ □ RKertiAMUMr/TWKWH
ШЯХИТ
JsmUft ASMXWQSTNXXmOMD
ИЛ AS WC7UQITN1XUDMD
>Л№ JUMXKfQJTWAWlWUl
loipig» SZfiHb» Z
imysige июм^ я
id^sagt S*H№ t
}фГЫ9» М45Чн К
Рис. 9.9. Мониторинг безопасности с использованием Amazon GuardDuty
Другие инструменты, которые могут использоваться для мониторинга безопас-
ности, — Imperva, McAfee, Qualys, Palo Alto Networks, Sophos и Symantec.
При установке средств мониторинга приложения очень важно контролировать
саму систему мониторинга. Обязательно организуйте мониторинг хоста системы
мониторинга. Например, если система мониторинга размещена в Amazon ЕС2
(Elastic Compute Cloud), то для контроля работоспособности ЕС2 можно ис-
пользовать AWS Cloud Watch.
Оповещения и реагирование на инциденты
Мониторинг — одна из составляющих операционного совершенства. Другой
составляющей является система оповещений (алертов) и реагирования на них.
Можно определять системные пороговые значения и условия срабатывания для
оповещений. Например, если загруженность сервера достигает 70 % в течение
5 минут, система мониторинга регистрирует факт высокой загруженности
и отправляет оповещение команде эксплуатации, чтобы та приняла меры для
снижения загруженности процессора до того, как система выйдет из строя. В ка-
честве реагирования на этот инцидент команда может добавить сервер вручную.
Если включена автоматизация, автомасштабирование выдает оповещение, что
необходимо добавить дополнительные серверы. При этом команде эксплуа-
тации отправляется уведомление, с которым она может разобраться позже.
Реагирование на инциденты необходимо для того, чтобы обработать полученные
оповещения и решить проблемы. Действия для решения проблем с перебоями
в работе системы или ошибками могут выполняться автоматически или управ-
ляться командой эксплуатации. Это гарантия того, что любые нарушения будут
быстро и эффективно устранены, а их последствия для деятельности организации
минимизированы. Таким образом обеспечиваются надежность и доступность
системы для пользователей и стейкхолдеров.
Выбор технологий для операционного совершенства 363
Полезно определить категории оповещений, чтобы команда эксплуатации была
готова реагировать в соответствии с серьезностью оповещения. Ниже показан
пример классификации оповещений по приоритетам.
• Уровень 1: критически важная проблема. Уровень 1 означает значительные
последствия для клиентов, требующие немедленного реагирования. Опо-
вещение уровня 1 может указывать на то, что все приложение вышло из
строя. Стандартное время реагирования на такие оповещения — 15 минут,
а решением проблемы необходимо заниматься в режиме 24/7.
• Уровень 2: высокоприоритетное оповещение, которое должно обрабатываться
в рабочее время. Например, приложение работает, но система оценок и от-
зывов для конкретной категории товаров — нет. Стандартное время реаги-
рования на такие оповещения — 24 часа, а решением проблемы необходимо
заниматься в рабочее время.
• Уровень 3: оповещение со средним приоритетом, которое может обрабаты-
ваться в рабочее время в течение нескольких дней, — например, оповещение
о том, что диск сервера будет заполнен через 2 дня. Стандартное время реа-
гирования на такие оповещения — 72 часа, решением проблемы необходимо
заниматься в рабочее время.
• Уровень 4: низкоприоритетное оповещение, которое может обрабатываться
в рабочее время в течение недели, — например, оповещение о том, что срок
действия сертификата SSL истечет через 2 недели. Стандартное время реа-
гирования на такие оповещения — неделя, решением проблемы необходимо
заниматься в рабочее время.
• Уровень 5: относится к категории уведомлений, не требует эскалации и мо-
жет быть простой информацией — например, уведомлением о завершении
развертывания. Ответной реакции не требует, так как существует только для
информационных целей.
Каждая организация может определять разные уровни серьезности оповещений
в зависимости от своих потребностей. Одним организациям достаточно четырех
уровней безопасности, другие могут определить шесть. Кроме того, различаться
может и время реагирования. Некоторые организации могут требовать реаги-
рования на оповещения уровня 2 в течение 6 часов в режиме 24/7, а не только
в рабочее время.
Настраивая оповещения, следите, чтобы их название и краткое описание были
содержательными и лаконичными, поскольку они часто отправляются на мо-
бильное устройство (в формате SMS) или пейджер (как текстовое сообщение)
и получатель должен немедленно отреагировать на них. Не забудьте включить
данные метрик в тело сообщения. Например, лучше указать конкретную инфор-
мацию вида «На сервере production-web-1 диск заполнен на 90 % » вместо простого
сообщения «Диск заполнен». На рис. 9.10 приведен скриншот из CloudWatch
с примером дашборда.
364
Глава 9. Операционное совершенство
Рис. 9.10. Дашборд оповещений
На скриншоте показано оповещение о том, что таблица базы данных NoSQL
Amazon DynamoDB с именем testretail демонстрирует низкую утилизацию
выделенных единиц записи, что создает лишние затраты.
Четыре нижних и два верхних оповещения имеют статус ОК, так как данные,
полученные в ходе мониторинга, лежат в пределах пороговых значений.
Иногда в оповещении может быть указано «недостаточно данных»; это
означает, что для определения состояния отслеживаемых ресурсов требуется
больше точек данных.
В случае критически важных оповещений важно протестировать реагирование
на инцидент, чтобы удостовериться, что поддержка готова отреагировать на него
в соответствии с условиями SLA. Проверьте правильность настройки порогов,
чтобы у вас было достаточно времени для решения проблемы, и не отправляйте
слишком много оповещений. Убедитесь, что сразу же после решения проблемы
оповещение возвращается в исходное состояние и снова готово к сохранению
данных событий.
Инцидентом считается любое незапланированное нарушение нормальной ра-
боты, которое отрицательно влияет на систему и клиента. Первой реакцией на
инцидент должно стать восстановление системы и взаимодействий с клиентом.
Устранением первопричины можно заняться позже, когда система будет восста-
новлена и начнет функционировать. Автоматизированное оповещение помогает
активно обнаружить инцидент и минимизировать последствия для пользова-
теля. Например, при выходе из строя всей системы можно переключиться на
площадку аварийного восстановления. Основная система будет исправлена
и восстановлена позже.
Выбор технологий для операционного совершенства 365
Компания Netflix использует Simian Army («Армию обезьян») (https://
netflixtechblog.com/the-netflix-simian-army-16e57fbabll6) — набор инструмен-
тов для тестирования устойчивости систем, включающий Chaos Monkey
(«обезьяну хаоса»). Chaos Monkey случайным образом завершает работу
продакшен-серверов, чтобы проверить, сможет ли система отреагировать на
аварийные ситуации без последствий для конечных пользователей. У Netflix
также имеются другие инструменты для тестирования различных измерений
системной архитектуры: Security Monkey (проверка уязвимостей безопас-
ности), Latency Monkey (задержки в сети) и даже Chaos Gorilla (моделирует
отказ целой зоны доступности).
Мониторинг, оповещения и реагирование на инциденты — важнейшие состав-
ляющие операционного совершенства. В любой системе мониторинга обычно
имеется встроенная функциональность оповещений. Полностью автоматизи-
рованная система оповещений и мониторинга улучшает способность команды
эксплуатации поддерживать работоспособность системы и применять свой опыт,
помогая быстро принимать меры и улучшать взаимодействие с пользователями.
В процессе мониторинга среды приложения очень важно проводить непре-
рывные улучшения и постоянно стремиться к совершенству. Рассмотрим тему
непрерывного улучшения более подробно.
Развитие операционного совершенства
Непрерывное улучшение необходимо для успеха любого процесса, продукта
или приложения. Операционное совершенство также нуждается в непрерывном
улучшении, чтобы со временем достичь зрелости.
При анализе первопричин (RCA, root cause analysis) рекомендуется вносить
небольшие инкрементные изменения. Умение пользоваться данными о про-
шлых сбоях поможет подготовиться к разным событиям, которые могут быть
как запланированными (например, развертывания), так и незапланированными
(например, резкий рост загруженности ресурсов). Регистрируйте всю инфор-
мацию и обновляйте рекомендации в ранбуке. Для развития операционного со-
вершенства понадобятся соответствующие инструменты в следующих областях:
• аналитика ИТ-операций (ITOA, IT operations analytics);
• анализ первопричин (RCA);
• аудит и отчеты.
Аналитика ИТ-операций
ITOA — практика сбора данных из различных ресурсов для принятия решений
и прогнозирования любых проблем, которые могут возникнуть. Следует ана-
лизировать все события и текущие операции с целью их усовершенствования.
Анализ отказов поможет спрогнозировать события и подготовить команду к со-
ответствующему реагированию.
366
Глава 9. Операционное совершенство
В крупной организации могут работать сотни систем, генерирующих огромный
объем данных. Реализуйте механизм сбора журналов событий, различных видов
рабочей активности и изменений инфраструктуры и храните эти данные в те-
чение определенного времени — например, 90 или 180 дней. ITOA использует
архитектуру big data для хранения и анализа терабайтов данных в разных местах.
Эта практика помогает выявить проблемы, которые невозможно обнаружить при
помощи отдельных инструментов, и определять зависимости между системами,
формируя целостное представление о происходящем.
Как показано на рис. 9.11, у каждой системы есть собственные средства монито-
ринга, которые помогают получить информацию и организовать обслуживание
отдельных ее компонентов. Для операционной аналитики эти данные должны
поглощаться централизованным приемником. Наличие всех операционных
данных в одном месте обеспечивает единый авторитетный источник, к кото-
рому можно обращаться с запросами и применять аналитику для получения
содержательных результатов.
Рис. 9.11. Применение big data в ITOA
Чтобы создать систему операционной аналитики, можно воспользоваться мас-
штабируемым хранилищем больших данных — например, Amazon S3 (Simple
Storage Service). Также можно хранить данные в локальном кластере Hadoop.
Для извлечения данных на каждом сервере может быть установлен агент Amazon
Выбор технологий для операционного совершенства 367
CloudWatch, который может отправлять все данные мониторинга в централи-
зованную систему хранения. Сторонние инструменты — такие, как ExtraHop
и Splunk — помогут с извлечением данных из разных систем.
После того как данные будут собраны в централизованном хранилище, мож-
но выполнить их преобразование, чтобы подготовить их к поиску и анализу.
Преобразование и очистка данных могут производиться в таких приложениях
больших данных, как Spark, MapReduce, AWS Glue и т. д.
Для визуализации данных можно воспользоваться любой программой бизнес-
аналитики — Tableau, MicroStrategy, Amazon QuickSight и т. д. Речь идет о по-
строении пайплайна ETL (Extract, Transform, Load) — подробнее о нем см. в главе
12 «Инженерия данных для архитектур решений».
Далее можно применить машинное обучение для прогнозного анализа буду-
щих событий. Машинное обучение более подробно рассматривается в главе 13
«Архитектура машинного обучения».
Анализ первопричин
Для непрерывного улучшения необходимо предотвратить повторное возник-
новение любых ошибок. Если вы правильно идентифицируете проблему, то
сможете разработать и применить эффективное решение. Важно добраться до
коренных причин проблемы, чтобы ее исправить.
Пять «почему» — простой, но эффективный метод выявления первопричины
проблемы. В методе пяти «почему» вы собираете команду на ретроспективный
анализ инцидента и задаете пять последовательных вопросов для выявления ре-
альных причин. Рассмотрим пример. Данные должны отображаться на дашборде
мониторинга приложения, но этого не происходит. Мы зададим пять вопросов
«почему», чтобы добраться до первопричин проблемы.
Проблема: на дашборде приложения не выводятся данные.
1. Почему: потому что приложение не может подключиться к базе данных.
2. Почему: потому что приложение получает ошибку при попытке подключения
к базе данных.
3. Почему: потому что сетевой браузер не настроен на порт базы данных.
4. Почему: потому что настройка порта выполняется вручную, а команда ин-
фраструктуры забыла об этом.
5. Почему: потому что у команды отсутствуют средства автоматизации.
Первопричина: ошибка ручной настройки при создании инфраструктуры.
Решение: реализовать средства автоматизированного создания инфраструктуры.
В рассмотренном примере на первый взгляд кажется, что проблема связана
с приложением. После анализа пяти «почему» выясняется, что существует более
серьезная проблема и необходимо внедрить автоматизацию для предотвращения
аналогичных инцидентов.
368 Глава 9. Операционное совершенство
Анализ первопричин (RCA) помогает командам документировать полученную
информацию и непрерывно дополнять ее для достижения операционного совер-
шенства. Убедитесь, что вы обновляете и поддерживаете ранбук, — это поможет
применять и распространять лучшие практики в команде.
Аудит и отчетность
Аудит — важнейшее условие выявления любой вредоносной активности в си-
стеме, вызванной внутренним или внешним вмешательством, и создания реко-
мендаций для решения этой проблемы. Аудит становится особенно важен, если
приложение должно соответствовать требованиям регулирующих организаций —
например, PCI, HIPAA, FedRAMP (Federal Risk and Authorization Management
Program) и ISO (International Organization for Standardization). Эти организации
должны регулярно проводить аудит и проверять каждую активность в системе,
чтобы подготовить отчет о соответствии и выдать сертификат.
Аудит необходим для предотвращения и выявления инцидентов безопасности.
Взломщик может незаметно проникнуть в систему и систематически похищать
информацию. Регулярные аудиты безопасности могут обнаружить скрытую
угрозу.
Обеспечьте регулярный аудит, чтобы выявлять ресурсы, работающие вхолостую
в то время, когда они не требуются. Определяйте потребность в ресурсах и до-
ступные мощности, чтобы грамотно планировать.
Аудит позволяет убедиться, что вы защитили свои ИТ-активы и лицензии,
а также обеспечили целостность данных и операций для достижения целей
организации.
На рис. 9.12 показан аудит данных в бакете Amazon S3 с использованием Amazon
Macie — сервиса безопасности данных и конфиденциальности, базирующегося на
машинном обучении и технологиях поиска шаблонов. Он был специально спро-
ектирован для выявления и защиты конфиденциальных данных в средах AWS.
Рис. 9.12. Отчет аудита данных из Amazon Macie
Достижение операционного совершенства на публичных облачных платформах 369
Отчет аудита данных на этом скриншоте включает отчеты о доступности данных,
шифрования и совместного использования данных, а также детали хранения
и информацию о размере данных.
Процедура аудита включает этапы планирования, подготовки, оценки и пред-
ставления отчетов. В отчете должны быть выделены все элементы риска,
а также необходимо определить последующие действия для решения откры-
тых проблем.
Достижение операционного совершенства
на публичных облачных платформах
Провайдеры публичных облачных платформ — AWS, GCP, Azure и т. д. —
предоставляют широкий выбор встроенных возможностей и рекомендаций для
достижения операционного совершенства в облаке — например, автоматизацию.
Следующие сервисы AWS помогут обеспечить операционное совершенство.
• Сервисы AWS для этапа планирования:
AWS Trusted Advisor: проверяет рабочую нагрузку на основе заданных
лучших практик и предоставляет рекомендации по их реализации.
AWS CloudFormation: с AWS CloudFormation вся рабочая нагрузка
может рассматриваться как код, включая приложения, инфраструктуру,
политику, управление и операции.
AWS Systems Manager: предоставляет возможность управления об-
лачными серверами для массовой установки исправлений, обновлений
и общего обслуживания.
• Сервисы AWS для этапа функционирования:
Amazon CloudWatch: предоставляет сотни встроенных метрик для мони-
торинга операций рабочей нагрузки и выдачи оповещений по достижении
определенных порогов. Он предоставляет систему централизованного
управления журналами и инициирует автоматизированное реагирование
на инциденты.
AWS Lambda: этот сервис AWS может использоваться для автоматизации
реагирования на операционные события.
• Сервисы AWS для этапа развития (улучшения):
Amazon OpenSearch: может использоваться для анализа данных жур-
налов с целью получения и применения аналитики для обучения на
основе опыта.
AWS CodeCommit: полученная на основе опыта информация может рас-
пространяться в библиотеках, скриптах и документации, сохраняемых
в центральном репозитории как код.
AWS обеспечивает функциональность для предоставления приложений и ин-
фраструктуры в виде кода. Эти средства помогают автоматизировать операции
370 Глава 9. Операционное совершенство
и реагирование на инциденты. С AWS неработоспособные компоненты можно
легко заменить работающими версиями и анализировать их без влияния на
продакшен-среду.
В AWS можно собирать и объединять журналы системных операций, актив-
ностей рабочей нагрузки и инфраструктуры для создания полной истории
операций — при помощи таких сервисов, как AWS CloudTrail. Затем можно
воспользоваться инструментами AWS для запроса и анализа операционных
журналов во времени. Этот анализ поможет выявить области потенциальных
усовершенствований и повысить эффективность и безопасность системы. В об-
лаке обнаружение ресурсов выполняется просто, так как все они находятся под
API- и веб-интерфейсами в одной иерархии. Вы также можете отслеживать
локальную рабочую нагрузку из облака. Для целей аудита безопасности в об-
лаке AWS Amazon GuardDuty и Amazon Detective предоставляют отличную
аналитику и подробные данные по многим учетным записям.
Операционное совершенство должно поддерживаться непрерывно. Каждый
сбой должен тщательно анализироваться для повышения производительности
и надежности приложения. Этот процесс требует понимания специфических
потребностей и характеристик нагрузки приложения и соответствующей адап-
тации стратегий эксплуатации. Более того, если документировать повседневную
активность в виде ранбука, следовать схемам решения проблем, пользоваться
автоматизацией и повышать осведомленность, эксплуатационная команда будет
готова к любым сбоям.
Повышение эффективности с CloudOps
Термином CloudOps обозначаются процессы, инструменты и лучшие практики
эффективной эксплуатации и управления облачными средами. К преимуществам
CloudOps относятся повышение эффективности, сокращение затрат, обеспечение
безопасности и комплаенса, ускорение восстановления после сбоев и возмож-
ность быстрого масштабирования.
Перечислим ключевые принципы CloudOps, применимые независимо от об-
лачных провайдеров.
• Настройка управления: реализуйте безопасную, хорошо спроектирован-
ную среду. Используйте такие инструменты, как AWS Organizations, Azure
Management Groups или Google Cloud Resource Manager для организации
и управления учетными записями. Обеспечьте соблюдение политик при
помощи таких инструментов, как AWS Control Tower, Azure Blueprints или
Google Cloud Policy Intelligence.
• Комплаенс: организуйте непрерывный мониторинг конфигурации при по-
мощи таких инструментов, как AWS Config, Azure Policy или Google Cloud
Security Command Center. Автоматизируйте проверки соответствия и ис-
правления для целей соответствия отраслевым стандартам.
Повышение эффективности с CloudOps 371
• Выделение ресурсов и оркестрация: ускорьте настройку среды при помощи
средств «инфраструктуры как кода» с инструментами AWS CloudFormation,
шаблонами Azure Resource Manager или Google Cloud Deployment Manager.
Применяйте такие инструменты, как AWS Service Catalog, Azure Service
Catalog или Google Cloud Service Catalog, для управления стандартизиро-
ванными портфелями ИТ-сервисов.
• Мониторинг и наблюдение: обеспечьте наблюдаемость при помощи таких
инструментов, как AWS Cloud Watch, Azure Monitor или Google Cloud
Operations Suite. Быстро выявляйте и диагностируйте проблемы для под-
держания производительности и надежности системы.
• Централизация операций: управляйте инфраструктурой в масштабе при по-
мощи таких инструментов, как AWS Systems Manager, Azure Automation или
Google Cloud Operations, для автоматизации и централизации управления,
улучшая операционную эффективность.
• Управление затратами: управляйте затратами и оптимизируйте их при по-
мощи таких инструментов, как AWS Cost Explorer, Azure Cost Management
или Google Cloud Cost Management. Планируйте бюджеты, проводите мони-
торинг затрат и выявляйте аномалии, чтобы держать затраты под контролем.
Придерживаясь практик CloudOps, вы сможете поддерживать целостную и эф-
фективную операционную платформу независимо от облачной среды.
Автоматизация является основой CloudOps. Она позволяет организациям управ-
лять сложными облачными средами с большей эффективностью и меньшим
количеством ошибок. Например, изменения инфраструктуры, которые при руч-
ной реализации создают высокий риск ошибок, автоматизируются при помощи
AWS CloudFormation или похожих средств, обеспечивая последовательность
и высокую скорость выполнения операции. Когда при мониторинге с помощью
таких инструментов, как AWS CloudWatch, обнаруживаются проблемы с произ-
водительностью, можно запустить автоматизированные действия для решения
этих проблем без ручного вмешательства.
Переход на принципы CloudOps начинается с основ управления и комплаенса.
Например, агентство диджитал-маркетинга может начать с защиты своих об-
лачных сред в соответствии с лучшими практиками, а затем уже переходить на
полную автоматизацию пайплайнов развертывания. С ростом агентства совмест-
ная работа команд становится решающим условием для распространения лучших
практик и инструментов. Начиная с организации управления и комплаенса
и постепенно внедряя автоматизацию, команды могут эффективно управлять
затратами и масштабировать свои операции.
С CloudOps весь жизненный цикл создания, развертывания, мониторинга и экс-
плуатации в облачных средах значительно упрощается, открывая возможности
для Agile-разработки и операционного совершенства.
372 Глава 9. Операционное совершенство
В качестве примера в книге мы рассматриваем AWS, но те же концепции
применимы для любых публичных облачных платформ - в частности, GCP
и Azure.
Узнать больше о CloudOps можно в другой нашей книге, «AWS for Solutions
Architects».
Итоги
Операционного совершенства можно достичь путем непрерывных улучшений
с учетом текущих потребностей и прошлого опыта. Используйте для разработ-
ки и управления приложениями методы, которые повышают эффективность
и обеспечивают высокую отзывчивость развернутых сред. Реализация лучших
практик в отношении рабочей нагрузки обеспечит достижение операционного
совершенства.
В этой главе вы узнали о принципах проектирования, которые помогают до-
биться операционного совершенства. Среди них — автоматизация операций,
непрерывное улучшение, инкрементный подход, прогнозирование сбоев и го-
товность к реагированию на сбои.
Вы узнали о разных этапах операционного совершенства и соответствующих
им технологиях. Для этапа планирования было рассмотрено применение IT AM
в целях отслеживания ИТ-активов и выявления зависимостей между ними с ис-
пользованием управления конфигурацией.
Вы узнали об организации оповещений и мониторинга на этапе функциониро-
вания, а также познакомились с разными видами мониторинга, включая монито-
ринг инфраструктуры, приложений, журналов, безопасности и платформы. Вы
узнали о важности оповещений и о том, как определять серьезность оповещений
и реагировать на них.
Для этапа развития операционного совершенства мы рассмотрели применение
аналитики на основе построения пайплайна big data, методы применения анализа
первопричин (RCA) с использованием пяти вопросов «почему», а также важность
аудита для защиты системы от вредоносной активности и незамеченных угроз.
Вы узнали об операционном совершенстве в облаке и встроенных инструмен-
тах, которые можно использовать для его обеспечения на облачной платформе
AWS. Глава завершилась описанием подхода CloudOps и его потенциала для
упрощения облачных операций.
К этому моменту вы узнали о лучших практиках в областях производительности,
безопасности, надежности и операционного совершенства. В следующей главе
будут представлены лучшие практики оптимизации затрат. Вы также изучите
инструменты и приемы оптимизации общих системных затрат, а также возмож-
ности применения разных инструментов на облачной платформе для управления
затратами на ИТ.
ГЛАВА 10
ОПТИМИЗАЦИЯ ЗАТРАТ
В предыдущей главе вы узнали об операционном совершенстве и применении
автоматизации. Автоматизация снижает риск человеческих ошибок, повышает
эффективность и в конечном счете снижает затраты. Оптимизация затрат на
архитектуру — важнейшее условие поддержания эффективной и жизнеспособ-
ной ИТ-среды. Для его выполнения требуется понимать и управлять ресурсами,
которые потребляют приложения, а также контролировать, что вы платите толь-
ко за то, что действительно вам нужно. В этой главе мы исследуем различные
стратегии оптимизации затрат, включая правильный подбор ресурсов, модели
ценообразования, а также инструменты для бюджетирования и управления
затратами.
Одна из главных целей любого бизнеса — повышение прибыли при обслужи-
вании клиентов. Затраты — одна из важнейших тем, обсуждаемых при запуске
проекта. Обновления приложений и добавление новой функциональности
в продукты зависят от доступного финансирования. Затраты на продукт должны
учитываться всеми участниками проекта, и их необходимо анализировать на
каждом этапе жизненного цикла продукта (от планирования до эксплуатации).
Эта глава поможет понять лучшие практики оптимизации затрат на ИТ-решения
и эксплуатацию.
Оптимизация затрат — непрерывный процесс, которым необходимо тщательно
управлять без ущерба для пользовательского опыта. Оптимизация означает не
снижение затрат, а сокращение бизнес-рисков за счет максимизации окупаемости
(ROI). Прежде чем планировать любые стратегии и действия по оптимизации
затрат, необходимо понять потребности клиентов. Часто клиенты, стремящиеся
к качеству, готовы заплатить более высокую цену.
В этой главе обсуждаются принципы проектирования для оптимизации затрат.
Вопрос затрат должен учитываться для каждого этапа и компонента архитекту-
ры. Вы узнаете, как правильно выбирать технологии для оптимизации затрат на
каждом уровне. Мы рассмотрим лучшие практики оптимизации затрат:
• принципы проектирования для оптимизации затрат;
• приемы оптимизации затрат;
374 Глава 10. Оптимизация затрат
• управление оптимизацией затрат на публичной облачной платформе;
• «зеленые» ИТ и их влияние на затраты.
К концу главы вы освоите различные методы оптимизации затрат без риска для
адаптивности бизнеса и его результатов, а также научитесь отслеживать затраты
и контролировать их. Впрочем, обо всем по порядку: начнем с принципов про-
ектирования для оптимизации затрат, то есть принципов, которые закладывают
фундамент для построения архитектуры с учетом затрат.
Принципы проектирования для оптимизации
затрат
Оптимизация затрат подразумевает повышение бизнес-ценности и миними-
зацию риска при сокращении издержек. Желательно планировать затраты на
приложение с оценкой бюджета и прогнозированием расходов. Чтобы добиться
экономии, необходимо ввести план оптимизации затрат и тщательно отслежи-
вать издержки.
Существует ряд принципов, которые способствуют оптимизации затрат; самые
распространенные из них рассматриваются в следующих разделах. Как вы убе-
дитесь, все принципы проектирования для оптимизации затрат тесно связаны
и взаимно дополняют друг друга. Рассмотрим их подробнее.
Вычисление суммарной стоимости владения
Часто организации упускают из вида совокупную стоимость владения (ТСО,
Total Cost of Ownership) и принимают решения на основании исходных затрат
на приобретение программ и сервисов, так называемых капитальных затрат
(СарЕх, Capital Expenditure). Хотя определить исходные затраты важно, в долго-
срочной перспективе главное значение имеет ТСО, которая включает как СарЕх,
так и операционные затраты (ОрЕх).
СарЕх — это цена, которую организации платят единовременно для приоб-
ретения программного и аппаратного обеспечения, а в ОрЕх входят затраты
на эксплуатацию, обслуживание и списание ПО и оборудования, а также на
обучение сотрудников. Чтобы принимать стратегические решения при расчете
окупаемости в долгосрочной перспективе, учитывайте как СарЕх, так и ОрЕх.
Например, при покупке холодильника, который будет работать в режиме 24/7,
вы обращаете внимание на показатель энергосбережения, чтобы не разориться
на электричестве. Вы готовы изначально заплатить больше, если знаете, что
общие затраты со временем будут ниже благодаря экономии на счетах за электро-
энергию. Теперь возьмем в качестве примера дата-центр. Он требует исходных
затрат на приобретение оборудования (СарЕх). Кроме того, создание дата-центра
подразумевает дополнительные текущие расходы (ОрЕх), в том числена обо-
грев и охлаждение, администрирование инфраструктуры, безопасность и т. д.
Принципы проектирования для оптимизации затрат 375
В типичном сценарии использования при приобретении и реализации про-
граммного обеспечения следует учитывать следующие затраты для вычисления
ТСО (рис. 10.1).
Рис. 10.1. ТСО для ИТ-приложения
Рассмотрим затраты более подробно. С каждым компонентом ТСО связаны
следующие стандартные затраты на тиражное ПО (например, Oracle или базы
данных MS SQL).
(Щ)
В категорию «тиражного», или стандартного коммерческого (off-the-shelf), ПО
входят готовые, массово выпускаемые приложения, предназначенные для
широкой аудитории со схожими потребностями - в отличие от заказного,
или специализированного (custom), ПО, адаптированного для специфических
требований конкретного бизнеса или пользователя.
• Затраты на приобретение и установку: единовременные затраты на по-
купку ПО и сервисов для его развертывания. К этой категории относятся
следующие затраты:
стоимость приобретения ПО с необходимыми пользовательскими ли-
цензиями;
затраты на оборудование, включая сервер и пространство для разверты-
вания ПО;
затраты на реализацию, состоящие из времени и усилий на подготовку
ПО к эксплуатации;
затраты на миграцию, включая перемещение данных в новую систему.
• Затраты на эксплуатацию и обслуживание: непрерывные затраты на под-
держание работы ПО для конкретного бизнес-сценария, включая следующее:
обслуживание и поддержка;
установка обновлений и патчей, часто выпускаемых вендорами для ис-
правления любых потенциальных ошибок;
специальные изменения, адаптирующие ПО к потребностям организации;
376 Глава 10. Оптимизация затрат
затраты на поддержание физического сервера в дата-центре;
безопасность;
продление лицензий.
• Затраты на персонал и повышение квалификации: затраты на обучение
персонала, чтобы работники могли использовать ПО для выполнения биз-
нес-операций. К этой категории относятся следующие затраты:
оплата администраторов приложения;
оплата сотрудников техподдержки;
оплата функциональных и технических консультантов;
обучение и средства обучения.
Существуют разные варианты оптимизации затрат, включая подписку на про-
дукты SaaS (Software as a Service) — такие, как платформа CRM (Customer
Relationship Management) от Salesforce. Модель SaaS в основном использует
подписку по количеству пользователей, а значит, нужно определить, полу-
чите ли вы желаемую экономию. Для большого количества пользователей
можно выбрать гибридный метод и использовать облако для управления
оборудованием по модели «инфраструктура как сервис», laaS (Infrastructure
as a Service), устанавливая тиражное ПО. В общем случае, если программное
обеспечение не удовлетворяет вашим требованиям, вы можете создать его са-
мостоятельно. В любом сценарии рассчитайте ТСО, чтобы понять, где можно
добиться максимальной окупаемости. Рассмотрим планирование бюджета
и прогнозирование, которые помогают в управлении общими затратами и до-
стижении окупаемости.
Планирование бюджета и прогнозирование
Каждый бизнес должен планировать свои расходы и рассчитывать окупаемость
(ROI). Планирование бюджета дает организациям и командам информацию
для управления затратами. Организации планируют долгосрочный бюджет на
срок от 1 до 5 лет, что помогает им вести бизнес на основании необходимого
финансирования. Затем бюджет распространяется на отдельные проекты и при-
ложения. В процессе проектирования и разработки решения команда должна
учитывать доступный бюджет. Бюджет призван количественно оценить по-
ставленные бизнесом цели. Прогнозирование предоставляет оценку того, что
делает компания.
Планирование бюджета — важная часть долгосрочного стратегического плани-
рования, а прогнозирование предоставляет оценку на тактическом уровне для
выбора направления бизнеса. Не имея бюджета и прогноза, вы быстро собьетесь
с пути и превысите расчетные затраты на разработку и эксплуатацию приложе-
ний. Термины «бюджет» и «прогноз» могут вызвать путаницу, поэтому поясним
различия между ними (табл. 10.1).
Принципы проектирования для оптимизации затрат 377
Таблица ЮЛ. Различия между бюджетом и прогнозом
Параметр Бюджет Прогноз
Определение Подробный финансовый план с описанием ожидаемых до- ходов, расходов и распреде- ления ресурсов за указанный период Обновленное предсказание финансовой эффективности компании на основании теку- щих тенденций и краткосроч- ных ожиданий
Период времени Обычно планируется на долго- срочный период — например, год Более динамичен; обновляет- ся регулярно (ежемесячно или ежеквартально)
Частота корректировки Корректируется относительно редко — например, раз в год или при значительных изме- нениях Обновляется регулярно на основании текущей ситуации и краткосрочных перспектив
Назначение Используется для принятия бизнес-решений, стратегиче- ского планирования и распре- деления ресурсов Используется для принятия обоснованных оперативных решений и корректировок на основании последних тенден- ций и предсказаний
Оценка эффективности Эффективность оценивается путем сравнения запланиро- ванных и фактических затрат и доходов Эффективность не оценива- ется относительно постав- ленных целей. Нужен для понимания потенциальной бу- дущей финансовой ситуации
Примеры Решения по реструктуриза- ции компании,планированию ежегодных затрат на марке- тинг и целевого объема про- даж за год Корректировка штатной чис- ленности, изменение марке- тинговых стратегий на осно- вании недавних результатов, обновление объема ожидае- мых доходов
Прогноз помогает предпринять немедленные действия, в то время как бюджет
может оказаться недостижимым из-за изменений на рынке. Как показано
на рис. 10.2, текущая информация по расходам в сравнении с историческими
прогнозами может побудить вас скорректировать расходы на следующий
месяц.
Как видно из приведенного отчета, бюджет с ежемесячным размером затрат $450
будет исчерпан к концу ноября 2024 года. В данном случае прогноз помогает
действовать и управлять затратами, чтобы оставаться в рамках бюджета.
В следующем разделе рассматривается механизм повышения эффективности
затрат за счет управления потребностями и сервисами.
378 Глава 10. Оптимизация затрат
Cost and usage graph
TdqI cost
$3,892.22
Corti ($)
6-XT
Average forecasted cost per month
$324.35
О Forecast — 80% prediction Interval
Рис. 10.2. Прогнозный отчет
Потребности и каталоги сервисов
Почти в каждой организации существует централизованная ИТ-команда, рабо-
тающая с внутренними партнерами — например, с командой разработки и ко-
мандами поддержки из разных бизнес-подразделений. ИТ-команда управляет
потребностями в ИТ-инфраструктуре, включая затраты на ПО, оборудование
и поддержку для управления хостингом приложений. Бизнес-партнерам часто
требуется более глубокое понимание затрат на их ИТ-сервисы. Например, ко-
манды разработки приложений зачастую совершают излишние траты на среды
разработки и тестирования, что увеличивает расходы.
Вы можете запрашивать прогнозы от разных подразделений заранее, что по-
может согласовать поставки ИТ-инфраструктуры в целом. Консолидируя все
требования в одном месте, организация может экономить благодаря масштабу.
Потребности всех подразделений объединяются, что ведет к снижению цен.
Например, при использовании сервисов публичных облачных платформ (напри-
мер, AWS, GCP или Azure) у компаний появляется возможность получить более
благоприятные расценки за счет закрытых ценовых соглашений (РРА, Private
Pricing Agreement) или корпоративных скидочных программ (EDP, Enterprise
Discount Program). Такие соглашения особенно выгодны для организаций
с высокими рабочими нагрузками, консолидирующих свои ресурсы у одного
Принципы проектирования для оптимизации затрат 379
облачного провайдера. Принимая на себя обязательства об определенном уровне
использования или оплаты, компании могут добиться более выгодных цен, что
ведет к значительной экономии.
Организации могут выбрать один из двух подходов:
• управление потребностями: для экономии затрат в существующих ИТ-
средах (где часто встречаются избыточные расходы) можно воспользоваться
подходом, основанным на потребностях. Он поможет повысить эффектив-
ность затрат в краткосрочной перспективе при введении нескольких новых
сервисов. Проанализируйте исторические данные, чтобы понять факторы,
управляющие потребностями, и случаи лишних приобретений. Разработайте
для ИТ-команды и бизнес-партнеров процесс, упрощающий понимание за-
трат на эксплуатацию ИТ-сервисов;
• управление каталогом сервисов: если возникает потребность в новых сер-
висах, а у вас слишком мало исторических данных, можно воспользоваться
подходом, основанным на сервисах. При этом подходе необходимо понимать
потребность в часто используемых сервисах и создать каталог. Например,
команда разработки запрашивает сервис Linux с базой данных MySQL для
создания среды разработки. В таком случае ИТ-команда может создать ката-
лог сервисов, который поможет команде разработки приобрести небольшой
сервер Linux с сервером базы данных. Точно так же можно определить набор
самых распространенных сервисов и повысить детализацию затрат.
Каждый подход способствует значительной экономии как в краткосрочной, так
и в долгосрочной перспективе. Тем не менее реализовать их довольно трудно,
так как приходится изменять процессы планирования и утверждения проекта.
Финансовая и бизнес-команда должны работать согласованно и понимать
четкую взаимосвязь между ростом бизнеса и повышением ресурсоемкости
ИТ. Модель затрат должна строиться на самом эффективном подходе с объ-
единением облачных и локальных сред, а также предложений от вендоров
тиражного ПО.
Отслеживание расходов
Чтобы получать информацию о расходах на отдельные системы, организуйте от-
слеживание расходов с привязкой к владельцам системы или бизнеса. Доступная
и детализированная финансовая информация помогает оценивать ROI, прово-
дить дальнейшую оптимизацию ресурсов и сокращать издержки. Кроме того,
можно рассчитать ежемесячные затраты каждого подразделения или проекта.
Сокращение затрат — общая ответственность, и вам понадобится механизм,
который обеспечит подотчетность каждого подразделения или сотрудника.
Во многих организациях внедряют механизмы show-back (демонстрация за-
трат, то есть информационный отчет о затратах) или charge-back (возмещение
затрат, то есть выставление счетов подразделениям за использование средств)
для распределения ответственности за расходы между подразделениями.
380 Глава 10. Оптимизация затрат
В случае show-back информация о расходах каждого подразделения содержит-
ся в централизованном счете, но фактическая оплата при этом не взимается.
В случае charge-back каждое подразделение в организации управляет своим
бюджетом при помощи мастер-счета плательщика. С мастер-счета подразде-
лениям компенсируются их расходы на ИТ-ресурсы исходя из фактического
потребления за месяц. Эти механизмы мотивируют каждое подразделение более
ответственно относиться к расходам.
При реализации контроля затрат в организации лучше начать с отчетов show-
back в качестве промежуточного этапа и переходить на схему charge-back по
мере становления организационной модели.
Чтобы сформировать сознательное отношение к расходам в каждом подразде-
лении, настройте оповещения, чтобы команды получали сигнал о приближении
к прогнозному или бюджетному объему потребления. Создайте механизм мо-
ниторинга и управления затратами, распределяя их соответствующим образом
между инициативными сторонами. Обеспечьте открытость информации, чтобы
сформировать ответственность за расходы каждой команды. Отслеживание за-
трат поможет лучше понять деятельность каждой команды.
Любая рабочая нагрузка индивидуальна; используйте модель ценообразова-
ния, которая подходит для вашей рабочей нагрузки, чтобы сократить затраты.
Установите механизмы, обеспечивающие достижение бизнес-целей за счет при-
менения лучших практик оптимизации затрат. Перерасходов можно избежать,
определив стратегию связывания подразделений с конкретными затратами
и использования метода перекрестного контроля.
Непрерывная оптимизация затрат
Если вы придерживаетесь лучших практик оптимизации затрат, то должны
хорошо соотносить затраты с текущей активностью. С течением времени всегда
можно сократить затраты для зрелых приложений, прошедших миграцию.
Оптимизацию затрат следует продолжать до тех пор, пока расходы на опре-
деление возможностей для экономии не станут выше сэкономленной суммы.
Пока этот показатель не будет достигнут, необходимо непрерывно отслеживать
расходы и искать новые возможности сокращения затрат. Один из методов —
экономить за счет исключения простаивающих ресурсов. Допустим, компа-
ния использует облачные сервисы для своих сред разработки, тестирования
и эксплуатации. Непрерывно отслеживая свои облачные расходы, компания
обнаруживает, что несколько экземпляров в среде разработки остаются не-
дозагруженными или простаивают, особенно во внепиковые часы. Чтобы со-
кратить затраты, компания реализует график автоматического отключения
этих экземпляров в то время, когда они не используются (например, по ночам
или в выходные). Такой подход значительно сокращает затраты компании на
облако, так как ресурсы оплачиваются только тогда, когда они задействуются.
Принципы проектирования для оптимизации затрат 381
Со временем практика выявления и устранения простаивающих ресурсов мо-
жет привести к значительной экономии, позволяя компании более эффективно
распределять свой бюджет.
Чтобы сбалансировать затраты на архитектуру и ее производительность, убеди-
тесь, что расходы на ресурсы эффективны и все ресурсы в системе загружены
(например, экземпляры серверов).
Метрики использования ресурсов, демонстрирующие аномально высокие или
низкие затраты, не должны применяться для принятия решений, так как это
может повредить бизнесу организации. Оценка метрик эффективности исполь-
зования без учета контекста может привести к искаженным интерпретациям
и ошибочным решениям. Так, если брать за основу данные пиковых периодов
(к примеру «черной пятницы» для интернет-магазинов), это может привести
к выделению большого количества избыточных ресурсов. В периоды меньшей
нагрузки ресурсы окажутся недозагруженными, что экономически неэффектив-
но. Необходимо анализировать подобные метрики с учетом контекста, чтобы
избежать ловушек и убедиться, что ресурсы распределяются разумно и в соот-
ветствии с фактической потребностью, а не на основании пиковых или нети-
пичных периодов использования. Это способствует предотвращению лишних
затрат и эффективному управлению ими.
Метрики уровня приложения необходимо тщательно продумать для опти-
мизации затрат. Например, введите политики архивации для управления
емкостью хранилища данных. Чтобы оптимизировать базу данных, проверьте
потребности в ее развертывании — например, насколько необходимо ее терри-
ториально-распределенное развертывание и соответствует ли обеспечиваемый
уровень операций ввода/вывода в секунду (IOPS) реальным потребностям.
Можно воспользоваться моделью SaaS, чтобы сократить нагрузку на адми-
нистрирование и поддержку, при этом сосредоточиться на приложениях
и бизнес-целях.
Чтобы выявить пробелы и применить необходимые изменения для сокраще-
ния затрат, следует реализовать процессы управления ресурсами и контроля
изменений на протяжении жизненного цикла проекта. Они помогут организа-
ции проектировать архитектуру по возможности оптимально и экономично.
Ищите новые сервисы и функциональность, которые напрямую сокращают
затраты.
В этом разделе были рассмотрены принципы проектирования, направленные на
оптимизацию затрат, начиная с эффективного планирования бюджета до актив-
ного мониторинга затрат и непрерывных стратегий экономии. Эти принципы
очень важны для того, чтобы архитектура не только удовлетворяла требованиям
к производительности и эксплуатации, но и соответствовала финансовым целям
и организация могла получить максимальную отдачу от вложений и миними-
зировать лишние расходы. Рассмотрим некоторые приемы, которые помогают
оптимизировать затраты и повысить окупаемость.
382 Глава 10. Оптимизация затрат
Приемы оптимизации затрат
Компании инвестируют в технологии, чтобы получить конкурентное преиму-
щество и продолжать быстрый рост. В условиях экономической нестабильно-
сти оптимизация затрат становится важной, но непростой задачей. Компании
тратят много времени на исследование и сокращение затрат на приобретение
и эксплуатацию оборудования и поиск поставщиков. Многие компании даже
совместно используют дата-центры, кол-центры и рабочие пространства для
экономии затрат. Иногда организации тратят больше времени на обновления,
чтобы избежать покупки нового дорогостоящего оборудования.
Организация может добиться более значительной экономии, анализируя свою
внутреннюю ИТ-архитектуру. Улучшение существующей архитектуры спо-
собно открыть перед компанией новые возможности, даже если это потребует
определенной корректировки бюджета. Рассмотрим приоритетные области,
в которых компании могут экономить средства и повышать свой доход такими
приемами, как переход в облако, упрощенная архитектура, визуализация и со-
вместно используемые ресурсы.
Сокращение архитектурной сложности
Хотя многие организации стремятся к централизованной ИТ-архитектуре, на
практике каждое бизнес-подразделение пытается создать собственный набор
инструментов. Отсутствие общего контроля приводит к появлению множества на-
кладывающихся друг на друга систем и несогласованности данных. ИТ-инициативы
в отдельных бизнес-юнитах ориентируются на краткосрочные цели.
В подобных ситуациях необходимо обеспечить соответствие целей подразделе-
ний долгосрочному организационному видению — например, цифровой транс-
формацией всей организации. Кроме того, дублирование усложняет обслужи-
вание и обновление систем. Простое определение стандартов и предотвращение
дублирования способствует сокращению затрат.
На рис. 10.3 представлена сложная архитектура (слева), в которой подразделения
работают в своих приложениях без стандартизации, из-за чего появляются при-
ложения-дубликаты с многочисленными зависимостями, — подобные архитек-
туры приводят к высоким затратам и рискам. Проведение любых экспериментов
занимает много времени, что приводит к потере конкурентных преимуществ.
Стандартизация процесса, разработка архитектурных паттернов, пригодных для
повторного использования, и создание семейства общих сервисов формируют
комплексную и гибкую основу для адаптивной среды. Применяя автоматизацию
на этой основе, организации могут упрощать эксплуатацию, избегать лишних
усилий и значительно сокращать свои затраты. Подобный комплексный под-
ход не только способствует операционному совершенству, но и повышает оку-
паемость, демонстрируя стратегическое совмещение архитектурных практик
с бизнес-целями для достижения оптимальной финансовой эффективности.
Приемы оптимизации затрат 383
Рис. 10.3. Архитектурная стандартизация
* Т t *
I 1*1
Веб-сервер
Бэкенд
База
данных
Прежде всего необходимо устранить дублирование и выявить возможности
повторного использования функциональности между подразделениями, чтобы
сократить сложность архитектуры. Включение этих повторно используемых
компонентов в каталог сервисов может значительно улучшить доступность
и эффективность. Каталог сервисов работает как централизованный репози-
торий, в котором команды могут находить и повторно использовать заранее
определенные архитектурные паттерны, сервисы и ресурсы. В ходе gap-анализа
(анализа разрывов) существующих архитектур вы найдете множество компонен-
тов и кода, который может повторно использоваться в рамках организации для
обеспечения бизнес-требований. Чтобы сократить сложность ИТ-архитектуры,
попробуйте найти готовое решение, которое подойдет вашему бизнесу и обес-
печит окупаемость. Разработка специализированного продукта должна стать
последним вариантом, если не найдется ничего другого.
Любое новое приложение должно иметь доступный механизм интеграции для
взаимодействия с существующей системой через RESTful-архитектуру. Гармони-
зация дизайна пользовательских интерфейсов между приложениями позволяет
создать набор стандартных UI-пакетов, которые могут повторно использоваться
во всех новых приложениях.
Точно так же другие модули могут повторно использоваться в сервис-
ориентированном проектировании. Паттерны RESTful-архитектур рассма-
тривались в главе 4 «Паттерны проектирования архитектур решений»; они
помогают хранить разные части программных продуктов по отдельности, но
так, чтобы они могли взаимодействовать друг с другом, образуя целостную
систему.
384 Глава 10. Оптимизация затрат
При модульном подходе каждая команда отвечает за разработку сервиса, который
может использоваться всеми командами в организации для предотвращения
дублирования. Вы как архитектор должны помочь команде создать сервис-
ориентированную архитектуру, где каждая команда рассматривает отдельные
компоненты архитектуры как сервис, который может разрабатываться неза-
висимо. С помощью микросервисной архитектуры можно разрабатывать все
приложение по модульной схеме. Если один компонент не работает, его можно
изменить без последствий для всего приложения. Например, платежный сер-
вис, разработанный для сбора платежей от клиентов интернет-магазина, также
может использоваться для перевода оплаты поставщикам в системе управления
поставщиками.
После создания централизованной архитектуры применение модульного
подхода способствует сокращению затрат. Расширение полномочий архи-
тектурной команды поможет согласовать вйдение подразделений с видением
компании и поддерживать другие параллельные проекты в рамках общей
стратегии. Кроме того, это обеспечит целостность в других критически важных
сервисах, о которых часто забывают, — например, юридических, финансовых
и кадровых.
С помощью архитектурной команды можно получить превосходную обратную
связь и убедиться в том, что проекты соответствуют требованиям бизнеса.
Контролируя общую архитектуру между командами, архитектор может дать
совет относительно того, будет ли дубликат проекта, процесса или системы
соответствовать потребностям бизнеса. Централизация архитектуры снижает
сложность и уменьшает технический долг, что приводит к повышению ста-
бильности и качества. Общая цель централизованной архитектуры заключа-
ется в повышении эффективности ИТ, поэтому эту тему стоит рассмотреть
подробнее.
Повышение эффективности ИТ
В наше время каждая компания использует и потребляет ИТ-ресурсы. На избы-
точные серверы, ноутбуки и программные лицензии, а также на высокую емкость
хранилища расходуются значительные средства. Лицензии — один из ресурсов,
которые иногда недоиспользуются, теряются, простаивают или устанавливаются
неправильно и требуют значительного финансирования. Централизованная
ИТ-команда может возглавить усилия по оптимизации лицензий, отслеживая
используемые и списывая лишние. Кроме того, можно добиться экономии за
счет оптовых скидок у поставщика.
Чтобы повысить эффективность ИТ, отмените проекты, которые не соответству-
ют требованиям, но используют дополнительное финансирование и ресурсы.
Кроме того, вы должны помогать командам следовать стратегии и осуществлять
поддержку неиспользуемых или не соответствующих ей проектов или регулярно
завершать их.
Приемы оптимизации затрат 385
Рассмотрите следующие методы оптимизации затрат.
• Проведите переоценку проектов с высокими затратами; возможно, их стоит
привести в соответствие с видением бизнеса. Переработайте проекты, которые
имеют высокую бизнес-ценность, но не оказывают прямого воздействия на
ИТ-стратегию.
• Понизьте приоритеты проектов с минимальной бизнес-ценностью, даже если
они соответствуют ИТ-стратегии.
• Отмените проекты с низкой бизнес-ценностью, не отвечающие комплаенсу.
• Выведите из эксплуатации или удалите неиспользуемые приложения.
• Замените старые унаследованные системы, модернизируя их для сокращения
затрат на обслуживание.
• Избегайте дублирования проектов за счет повторного использования суще-
ствующих приложений.
• По возможности консолидируйте данные и разрабатывайте интегрирован-
ную модель данных. Централизованные хранилища данных более подробно
рассматриваются в главе 12 «Инженерия данных для архитектур решений».
• Консолидируйте внешние поставки в пределах организации, чтобы сэконо-
мить на поддержке и обслуживании.
• Консолидируйте любые системы, которые делают то же, что платежные
системы и системы управления доступом.
• Избавляйтесь от затратных, неэкономных, излишних проектов и расходов.
Перемещение в облако может стать отличным вариантом эффективного рас-
ширения ИТ-ресурсов и сокращения затрат. Провайдеры публичных облачных
платформ (таких, как AWS) предоставляют модель оплаты по мере фактического
использования ресурсов; это означает, что вы платите только за то, что реально
используете. Например, можно отключать десктопную систему разработчика
на выходные и нерабочее время, что позволит сократить затраты на рабочее
место до 70 %. Система пакетной обработки должна запускаться только для об-
работки заданий, после чего ее можно почти сразу же выключить. Она работает
как любой электроприбор, который выключается, когда не используется, чтобы
сэкономить расходы на электричество.
Применение автоматизации — отличный механизм повышения общей эффектив-
ности ИТ. Автоматизация помогает избавиться от дорогостоящего человеческого
труда и сокращает время выполнения повседневных рутинных задач, снижая
риск ошибок. Автоматизируйте все что возможно: выделение серверов, запуск
заданий мониторинга, обработку данных и т. д.
Принимая решение об оптимизации затрат, старайтесь выдерживать разумный
баланс для улучшения результатов. Рассмотрим пример. Если вы идете в парк
развлечений, где много интересных аттракционов, то вы согласитесь заплатить
высокую цену за вход. Если владелец парка решит снизить цену, но при этом
сократит количество интересных аттракционов, вы можете пойти в другой парк,
386 Глава 10. Оптимизация затрат
чтобы хорошо провести время. Конкуренты получат преимущество и привлекут
новых клиентов, тогда как текущий поставщик потеряет свою долю рынка. В та-
ком случает сокращение затрат повышает риск для бизнеса, что нельзя считать
хорошим методом оптимизации затрат.
Ваши цели должны быть количественно измеримыми, а метрики должны измерять
бизнес-результаты и затраты. Цели уровней организации и команд должны соот-
ветствовать целям конечных пользователей приложения. На уровне организации
цели должны ставиться между подразделениями. На уровне команды они будут
в большей степени соответствовать конкретным системам. Например, можно уста-
новить цель уровня бизнес-подразделения для сокращения затрат на транзакцию на
10 % за квартал или на 15 % каждые шесть месяцев. Определение целей гарантирует,
что системы будут совершенствоваться на протяжении своего жизненного цикла.
А теперь посмотрим, как применять стандартизацию и управление.
Применение стандартизации и управления
Организациям нужна стратегия для анализа несоответствий и чрезмерного потреб-
ления, сокращения сложности, определения рекомендаций для использования
наиболее эффективных систем и реализации процессов там, где они необходи-
мы. Создание и внедрение этих рекомендаций помогут компаниям разработать
стандартную инфраструктуру, сократить дублирование проектов и сложность.
Чтобы реализовать рациональное управление, следует установить ограничения
ресурсов в пределах организации. Создание каталога сервисов в рамках 1аС («ин-
фраструктура как код») позволяет следить за тем, чтобы командам не выделялись
ресурсы свыше установленной для них нормы. Вам понадобится механизм, который
позволит быстро понять бизнес-требования и совершать необходимые действия.
При установлении ограничений ресурсов и определении процесса изменения
этих ограничений следует учитывать создание и вывод ресурсов из эксплуатации.
®В рамках 1аС вся подготовка инфраструктуры от сетей и серверов до баз
данных и сервисов приложений может определяться в файлах с кодом на
таких языках, как YAML или JSON. Эти файлы могут участвовать в системах
контроля версий, позволяя командам отслеживать изменения во времени,
возвращаться к предыдущим конфигурациям и применять одинаковые
конфигурации в разных средах, обеспечивая согласованность и сокращая
дрейф конфигураций. Для применения 1аС могут использоваться такие
популярные инструменты, как Terraform, AWS CloudFormation и Ansible,
позволяющие командам определять 1аС и применять эти определения для
создания или изменения инфраструктуры.
Компании обычно используют множество приложений, разрабатываемых раз-
ными командами из различных бизнес-подразделений. Определение затрат на
ресурсы на уровне приложений, подразделений или команд способствует эф-
фективному использованию ресурсов и сокращению затрат. Ресурсную емкость
Приемы оптимизации затрат 387
можно определить на основании правильного отнесения затрат и на основе
потребностей групп, подразделений или отделов. Для организации структуры
затрат можно пользоваться тегированием ресурсов и структурированием счетов.
Как показано на рис. 10.4, счета могут структурироваться по разным подраз-
делениям (OU, Organizational Unit): кадры, финансы, маркетинг и т. д., — при
этом каждый отдел в подразделении может иметь собственные счета. Например,
на диаграмме отдел персонала (HR) имеет разные счета для начисления зарплат
и маркетинга, тогда как в отделе финансов используются отдельные счета для
продаж и маркетинга.
Organizational structure
▼ □ Й Root
r-4y4D
▼ О D Finance
w-4y40-c51 Sleps
► С D Marketing
0U-4y40-1yjfnlgs
► □ Ci Sales
ou-4y4O*v1 qscr4
C ® user2_ou1
J | шег2фатахоп.согп
* □ Cl HR
CMJ-4y4O-bzbq 1 Sfc
► CD Marketing
ou-4y4O- mn85f ry
► Ой Payroll
OlMy4(M54lqwfo
□ ® user3_ou2
Д | uscr30amazon.co<n
□ 0 user4_ou2
Д | uMr4^«nazon.com
Рис. 10.4. Корпоративная структура счетов для подразделений
388 Глава 10. Оптимизация затрат
В этой схеме структурирования счетов можно управлять затратами на уровне
каждого подразделения и отдела. Внедрение механизма charge-back для каждого
отдела повышает ответственность за затраты на более детализированном уровне,
что способствует их оптимизации.
Структурирование счетов помогает применять высокие стандарты безопасности
и комплаенса в организации. Так как каждый счет связывается с родительским
счетом, вы можете в значительной мере решить задачу массового использования
ресурсов поставщика, консолидируя расходы в организации.
Тегирование затрат ресурсов
Почти каждый провайдер публичных облачных платформ предоставляет гото-
вую функциональность тегирования (tagging). В разметку можно встраивать
метаданные серверов — например, имя DNS или имя хоста для локальных сред.
Теговая разметка помогает упорядочить затраты и определить пределы емкости,
критерии безопасности и комплаенса. Она может стать отличным инструментом
для управления запасами и наблюдения за растущими потребностями в ресурсах
на каждом уровне организации.
Тегирование ресурсов становится мощной стратегией управления и оптимиза-
ции затрат в облачных вычислительных средах. Она включает назначение тегов
метаданных для облачных ресурсов (виртуальных машин, экземпляров храни-
лищ или баз данных) с целью их классификации и отслеживания на основании
различных критериев: проектов, сред, отделов, центров затрат.
Как видно из рис. 10.5, для получения полной видимости затрат и консолидации
между ресурсами можно пометить тегом каждый ресурс, предоставляемый на
уровне команды, что обеспечивает более детализированный контроль.
Add another tag (Up to 60 tags maximum)
Рис. 10.5. Тегирование ресурсов для обеспечения видимости затрат
Приемы оптимизации затрат 389
На этой диаграмме мы видим стратегию тегирования, которое указывает, что
сервер предназначен для развертывания приложения (Type: AppServer) и ис-
пользуется командой разработки (Environment: Dev). Владельцем сервера
является отдел маркетинга (Department: Marketing) финансового подразделе-
ния (Busines Unit: Finance). При таком подходе организация может получить
детализированную информацию о расходах, и команды будут более экономны.
Впрочем, можно применить механизм show-back на уровне команд и механизм
charge-back на уровнях отделов и подразделений.
Можно внедрить собственный механизм тегирования, который позволит при-
соединить к любому ресурсу имя и значение (например, имя ресурса и имя
владельца). На рис. 10.6 представлены затраты, отсортированные по тегу
aws: created By; этот список помогает определить затраты на каждый ресурс,
автоматически вычисляемые AWS.
cost and usage graph №
$4,021.32
Av? racfe monthly c«t
$365.57
gwsxiMtedBy count
17
6C0
Jan 2023 №2023 MW 2023 Apt 2023 May2023 Jun2O2S AL 2023 Aug 2023 Sflp 2023 №2U23 N0V2Q23'
Рис. 10.6. Дашборд расходов на ресурсы для заданного тега
Руководителям бизнеса необходимо оценивать общие требования для создания
эффективных ИТ-архитектур. Для разработки надежной ИТ-архитектуры тре-
буется сотрудничество между функциональными командами, чтобы установить
систему управления и четко определить области ответственности. Кроме того,
следует разработать стандарт для анализа архитектуры, задать основные исход-
ные параметры для любых новых инициатив и провести разъяснение процесса,
чтобы обеспечить соответствие системы архитектурным нормам и выявить воз-
можности для усовершенствования.
Привлеките всех стейкхолдеров к обсуждению затрат и использования ресурсов.
Финансовый директор и владельцы приложений должны понимать потребление
ресурсов и варианты приобретений. Руководители отделов должны понимать
общую бизнес-модель и процесс ежемесячного выставления счетов. Это поможет
задать направление для подразделений и компании в целом.
390 Глава 10. Оптимизация затрат
Убедитесь, что внешние поставщики действуют в соответствии с вашими
финансовыми целями и могут корректировать свои модели участия. Постав-
щики должны представить анализ затрат для любого приложения, которым
они владеют и которое разрабатывают. Каждая команда в организации должна
быть способна перевести факторы бизнеса, затрат и использования ресурсов из
плоскости управления в действия по настройке системы, чтобы приложения
могли достигать целей компании.
Мониторинг затрат и отчеты
Точные данные о затратах помогают определить прибыльность подразделений
и продуктов. Отслеживание затрат помогает распределять ресурсы для повы-
шения окупаемости. Понимание затрат помогает управлять расходами бизнеса.
Чтобы оптимизировать затраты, необходимо знать паттерны расходов в орга-
низации. Следует также иметь представление о расходах ИТ во времени, чтобы
определить возможности экономии. Для оптимизации затрат и понимания ее
последствий можно создать наглядное представление трендов затрат с истори-
ческими данными и прогнозами для разных ресурсов и отделов в организации.
Следует собирать все необходимые данные, регистрировать все точки данных,
анализировать их в ходе мониторинга и создавать наглядные отчеты.
Чтобы выявить возможности для экономии, понадобится подробная инфор-
мация об использовании рабочих ресурсов. Оптимизация затрат зависит от
вашей способности прогнозировать будущие расходы и соотносить затраты с ис-
пользованием ресурсов с прогнозами. Ниже перечислены основные сценарии,
в которых понадобится визуализация данных:
• определение самых крупных инвестиций в ресурсы;
• анализ и понимание расходов и данных по использованию ресурсов;
• бюджет и прогнозирование;
• получение оповещений при превышении бюджетных или прогнозных порогов.
На рис. 10.7 показан отчет о стоимости ресурсов в AWS за шесть месяцев. Из
визуализации видно, что на облачный вычислительный сервер ЕС2, представ-
ленный пятым столбцом за каждый месяц, приходились самые высокие затраты
с мая по июль 2023 года. Так как подразделение постоянно видит на диаграмме
высокие затраты, системному администратору необходимо вплотную заняться
оптимизацией затрат и выявлением простаивающих ресурсов. Администратор
остановил эти серверы ЕС2, что привело к снижению затрат в августе и их пол-
ному исключению начиная с сентября.
Предыдущий отчет помог владельцам бизнеса понять паттерны затрат и при-
менить реактивный подход к управлению затратами. Реактивный подход поро-
дил скрытые затраты, которые оставались незамеченными за рассматриваемый
период. С проактивным подходом прогноз помог владельцам бизнеса принять
упреждающее решение.
Приемы оптимизации затрат 391
Cost «nd usage graph м»
Total tost
$2,222.27
Average monthly <o$t
$37038
Sendee couni
35
May 2023 Jun 20? 3 Jul 2023 Aug 2023 Sep 2023 Oct 2023
7|Aud»L Manager ВОимП^И Elastic tart Balancing В Workspaces Ecl-HSisows дНОШмяу BHresK BeClOihcr BSccurttyHub
Mothers
Рис. 10.7. Отчет о стоимости ресурсов и их использовании по сервисам
Отчет на рис. 10.8 показывает диапазоны ежемесячных расходов (заполненные
прямоугольники) и прогнозируемых затрат (пустые прямоугольники). Из от-
чета следует, что затраты с большой вероятностью возрастут за ближайшую
пару месяцев, и можно принять меры к тому, чтобы понять факторы затрат
и контролировать их.
Cost and usage graph
ofi cost (historical and fc recr^teC
$2,264.71
Average historical cwt per month
$278.58
Дччде forKirj c- rt р^гпнnil.
$322.19
AU9?OH Stp2C2J OctiOJS Hw2O2S" Ok 2023" Jan 2024" №2024"
CbsU CJFbncst — 804 prediction Interval
Рис. 10.8. Отчет о затратах с прогнозом
392 Глава 10. Оптимизация затрат
Мониторинг затрат относительно бюджета может привести к дополнительным
проактивным мерам для контроля затрат. Выдача оповещения при расходовании
определенной части бюджета (50 или 80 %) поможет проанализировать и скор-
ректировать текущие затраты.
В отчете на рис. 10.9 можно наглядно сравнить текущие затраты с бюджет-
ными; год назад они были достаточно высокими. На основании этого отчета
ИТ-администраторы могут принять меры по оптимизации затрат и их приве-
дению в границы ежемесячного бюджета.
Cost and usage graph ни
ТЙН1СМГ
$5,267.76
MBrttNy СоЯ
$438,98
In
NOV 2022 №2022 Jan 2023 Feb 2Й23 Mar 2023 Apr 2023 May 2023 Jdn2O25 Jul 2023 Aug 2023 Sep 2025 № 2023
Рис. 10.9. Отчет о затратах и бюджете
Отчеты о затратах и бюджете позволяют контролировать затраты, действуя
проактивно. Соотнесение фактических затрат с бюджетами и прогнозами предо-
ставляет широкие возможности для повседневного контроля затрат.
Также можно настроить оповещение при достижении фактическими затратами
определенного порога в бюджете или прогнозе. Такое оповещение отправляется
по электронной почте или SMS и указывает на необходимость проактивного
контроля над затратами.
На рис. 10.10 показано, что оповещение отправляется при превышении оце-
ночными затратами порога $500. Можно настроить несколько оповещений,
уведомляющих, что затраты достигли, скажем, порога $300 и $400.
Один из способов контроля затрат — это оптимальное выделение ресурсов (right-
sizing) с мониторингом ресурсов и отправкой оповещений при чрезмерной или
недостаточной загруженности. Анализ ресурсов может выполняться с помощью
таких средств мониторинга, как Splunk, CloudWatch или специализированные
журналы, а для их оптимального выделения помогут специализированные
Приемы оптимизации затрат 393
Conditions
Threshold type
Static
Whenever Estimated Charges I3
drearer{>)
than...
500
Рис. 10.10. Оповещения на основе фактических затрат
метрики — например, использование памяти приложениями. Низкое потребление
ресурса может стать критерием для выявления возможностей сокращения затрат.
Например, можно анализировать и отслеживать загрузку процессора и памяти,
пропускную способность сети и количество подключений к приложению.
Будьте осторожны при изменении масштабов инфрастуруктуры, чтобы это
не отразилось на качестве пользовательского опыта. Назовем рекомендуемые
лучшие практики для оптимального выделения ресурсов.
• Позаботьтесь о том, чтобы мониторинг отражал опыт конечных пользо-
вателей. Выберите правильный период времени. Например, метрики про-
изводительности должны покрывать 99 % пользовательского времени на
запрос-ответ, а не просто среднее время ответа.
• Выберите подходящий цикл мониторинга: каждый час, день или неделю.
Например, при проведении ежедневного анализа вы можете упустить
394
Глава 10. Оптимизация затрат
еженедельный или ежемесячный цикл повышенной нагрузки и выделить
недостаточно ресурсов для системы.
• Сравнивайте затраты на изменения с экономией. Возможно, вам придется
провести дополнительное тестирование или привлечь ресурсы для измене-
ния масштабов. Анализ затрат и выгод поможет в распределении ресурсов.
• Сверяйте нагрузку на приложение с бизнес-требованиями. Например,
посмотрите, сколько пользовательских запросов вы ожидаете получать
к концу месяца или во время пиковой нагрузки. Выявление и оптимизация
несоответствий в нагрузке поможет с сокращением расходов. Используйте
подходящий инструмент, который учитывает все измерения, от эконо-
мии до загруженности системы и влияния изменений на взаимодействия
с пользователями, затем используйте отчеты, чтобы понять, как изменения
затрат влияют на окупаемость бизнеса. Публичные облачные платформы
применяют другую модель ценообразования, часто с оплатой по фактиче-
скому использованию.
При использовании облачных ресурсов необходимо действовать очень аккуратно,
так как каждая секунда увеличивает затраты, и упущения в оптимизации и мони-
торинге затрат могут обойтись дорого. В следующем разделе тема оптимизации
затрат на публичных облачных платформах рассматривается более подробно.
Оптимизация затрат на публичных
облачных платформах
Публичные облачные платформы — такие, как AWS, Microsoft Azure и GCP —
предоставляют отличные возможности оптимизации затрат с моделью оплаты
по фактическому использованию. Эта модель позволяет клиентам заменить
капитальные расходы (СарЕх) переменными, оплачивая ИТ-ресурсы по мере
потребления. Операционные расходы (ОрЕх) обычно снижаются вследствие
экономии на объеме. Может быть экономически эффективно получать пре-
имущество от снижения цен пропорционально времени работы в облаке. Другое
преимущество заключается в том, что с облачным провайдером (таким, как AWS)
вы получаете готовые дополнительные инструменты и функциональность для
более адаптивной архитектуры.
При определении модели для структуры облачных затрат необходим другой
подход, так как она отличается от традиционных моделей затрат, которые десяти-
летиями использовались большинством компаний. В облаке вся инфраструктура
находится прямо под рукой, что требует большей степени контроля и регулиро-
вания. Облачные платформы предоставляют инструменты для рационального
управления затратами и систематизации. Например, в AWS можно установить
ограничения, чтобы команда разработки не могла использовать более 10 сер-
веров, а команде эксплуатации выделяется необходимое количество серверов
и баз данных с буфером.
Оптимизация затрат на публичных облачных платформах 395
Все ресурсы связываются с учетными записями в облаке, что позволяет легко
отслеживать и контролировать их нагрузку. Кроме того, вы получаете инстру-
менты сбора данных по разным ИТ-ресурсам и предоставления рекомендаций.
Как показано на рис. 10.11, AWS Trusted Advisor обходит все ресурсы в учетной
записи и предлагает рекомендации по экономии в зависимости от степени их
использования.
Cost optimization
CMMtl <ма МПМ К№С«Г*«ПМММ kr irivtK Мр 1М Я*М*у Г« I
емко₽V iwtn i ctitda
* А МЙ UmMeniMtkMw№iHMiE'nrRi№
С И
иФЪш hMtamwM Hpi «nr пси tfw nw гака MHhtML
Рис. 10.11. Рекомендации по снижению затрат от AWS Trusted Advisor
На скриншоте видно, что AWS Trusted Advisor обнаружил простаивающий
балансировщик нагрузки и рекомендует отключить его, чтобы сократить еже-
месячные затраты до $40. Дальнейшие проверки обнаружили Lambda-функцию
с высокой частотой ошибок; ее необходимо исправить для сокращения затрат.
Облачная платформа может предоставить отличные возможности для экономии.
Для начала можно создать гибридное облачное решение и установить в нем связь
между локальным дата-центром и облаком. Серверы разработки и тестирования
можно перенести в облако, чтобы определить структуру затрат и потенциальную
экономию. Когда вы настроите рациональное управление затратами в облаке,
переходите к переносу других рабочих нагрузок на основании анализа затрат
и выгод. При этом необходимо оценить рабочую нагрузку, понять, можно ли
переместить ее в облако, и если можно — определить стратегию. Облачная
миграция рассматривалась в главе 3 «Миграция на облачные платформы и про-
ектирование облачных архитектур».
Провайдеры публичных облачных платформ также предоставляют управляемые
сервисы, избавляя от любых затрат на обслуживание инфраструктуры и лиш-
них расходов на настройку оповещений и мониторинга. Управляемый сервис
396
Глава 10. Оптимизация затрат
сокращает общую стоимость владения за счет сокращения затрат с повышением
уровня внедрения сервиса.
Публичные облачные платформы предлагают планы экономии или зарезерви-
рованные экземпляры, которые позволяют организациям принять обязательства
по определенному уровню использования в обмен на значительно более низкую
цену по сравнению с тарификацией по требованию. На основании анализа данных
использования ресурсов организации могут принимать обоснованные решения
о приобретении этих планов, приводя свои обязательства в соответствие с фак-
тическими шаблонами использования для максимальной экономии.
Внедрение планов экономии в стратегию оптимизации облачных затрат по-
зволяет организациям соблюдать баланс между гибкостью и эффективностью
затрат. Они могут сохранить адаптивность модели оплаты по фактическому ис-
пользованию для переменных рабочих нагрузок, но при этом получить прибыль
благодаря планам экономии для прогнозируемого, стабильного использования,
что гарантирует эффективную оптимизацию их облачных расходов.
Термином «зеленые ИТ» (Green IT) обозначается экологически ответственное
и экологически чистое использование компьютеров и их ресурсов. Оно ох-
ватывает такие практики, как сокращение энергопотребления, минимизация
электронных отходов и проектирование дата-центров с меньшим потреблением
энергии. Эта тема более подробно рассматривается в следующем разделе.
Зеленые ИТ и их влияние на затраты
Зеленые ИТ (или зеленые вычисления) подразумевают изучение и практику
использования компьютеров и ИТ-ресурсов более эффективным и экологически
устойчивым образом. Практики зеленых ИТ значительно влияют на затраты по
нескольким направлениям.
• Энергетическая эффективность: использование энергетически эффективного
оборудования и практик может сократить энергопотребление дата-центров
и ИТ-инфраструктуры, что приводит к значительной экономии расходов на
электричество. Например, использование оборудования стандарта Energy
Star или оптимизация планировки дата-центров для охлаждения может по-
низить расходы на энергопотребление.
• Виртуализация: виртуализация серверов и хранилища может привести
к сокращению потребностей в физическом оборудовании. Таким образом
сокращаются энергопотребление и затраты, связанные с охлаждением, и ми-
нимизируется пространство, необходимое для дата-центров.
• Облачные вычисления: переход на облачные сервисы может быть более энерго-
экономичным, чем содержание локальных дата-центров. Облачные провайдеры
часто предлагают варианты экономии за счет объема, а их дата-центры более
современны, эффективны и экологичны. Благодаря этому можно снизить рас-
ходы на электроэнергию и охлаждение, а также сократить углеродный след.
Зеленые ИТ и их влияние на затраты 397
• Переработка и повторное использование оборудования: правильно органи-
зованная переработка и повторное использование ИТ-оборудования могут
способствовать экономии. Компании могут окупить часть своих исходных
вложений за счет переработки или продажи старого оборудования. Кроме того,
восстановленное оборудование может обойтись значительно дешевле нового.
• Удаленная работа: переход на модель удаленной работы сокращает необхо-
димость в офисах, энергопотреблении и затратах на доставку работников.
Это может привести к прямой и косвенной экономии затрат для организации
и работников с одновременной пользой для среды.
• Электронный документооборот: сокращение расхода бумаги за счет внедре-
ния электронного документооборота может способствовать экономии затрат
на бумагу, печать и хранение, а также пользе для окружающей среды за счет
снижения бумажных отходов.
• Приобретение устойчивых ИТ-ресурсов: выбор поставщиков и продуктов,
уделяющих особое внимание устойчивости, может способствовать экономии
затрат в долгосрочной перспективе. Продукты, спроектированные с расчетом
на большую надежность или с расширенными гарантиями, могут требовать
более высоких исходных затрат, но иметь более низкую совокупную стоимость
владения с течением времени.
• Оптимизация обслуживания: регулярные обслуживание и обновление могут
продлить жизнь ИТ-оборудования, откладывая необходимость в заменах
и сокращая объем электронных отходов.
• Утилизация ИТ-ресурсов: эффективное управление утилизацией ИТ-
ресурсов может сократить затраты на обработку отходов и обеспечить соот-
ветствие экологическим нормативам, чтобы избежать возможных штрафов.
• Углеродные кредиты: сокращая углеродосодержащие выбросы за счет при-
менения зеленых ИТ-практик, организации могут зарабатывать углеродные
кредиты, которые можно продавать или обменивать. Таким образом обес-
печивается потенциальный канал поступления доходов или экономии на
углеродных налогах.
Зеленые ИТ могут способствовать значительной экономии в организациях за
счет сокращения энергопотребления, минимизации отходов, оптимизации ис-
пользования оборудования и улучшения общей устойчивости. Такая экономия
часто компенсирует исходные вложения, необходимые для реализации инициа-
тив зеленых ИТ. В следующем разделе вы узнаете, как облачные провайдеры —
такие, как AWS — способствуют внедрению зеленых ИТ в организации.
Размещение экономичных и зеленых приложений в AWS
Внедрение зеленых ИТ с участием AWS основано на преимуществах, которые
дает облачная инфраструктура в части экологии и экономической эффективности.
AWS предоставляет сервисы, поддерживающие инициативы зеленых ИТ (бес-
серверные архитектуры, энергоэкономичные дата-центры, средства оптимизации
398 Глава 10. Оптимизация затрат
ресурсов и т. д.). AWS проактивно поддерживает зеленые ИТ и цели устойчивости
через различные инициативы и сервисы, которые позволяют клиентам сокращать
свой углеродный след и оптимизировать использование энергии.
В среде AWS существует клиентский инструмент для определения углеродного
следа, показанный на рис. 10.12. Он предоставляет визуализации историче-
ских данных по углеродным выбросам, тенденциям выбросов в ходе эволюции
AWS, оценки выбросов, предотвращенных за счет использования AWS вместо
локальных дата-центров, и прогнозирование выбросов на основании текущего
использования.
* СийопнСиЪоп footprint Тм4 w.
[мамт * ] [мдш * в ptiirtiH |
Vour HihaioH by senates
СгЬмнНЛми
OwrffiPa
сечка»
bDMMTCOlr
IWHrtOh
Рис. 10.12. Отчет об углеродном следе
В представленном отчете приводятся данные об углеродном следе за послед-
ние два года; в отчет включены данные о потреблении углеродных выбросов
и экономии. Углеродный след изменится по мере перехода AWS на 100 % возоб-
новляемой энергии к 2025 году и к 2040-му станет нулевым.
AWS имеет достаточно подробные рекомендации по созданию экологически
устойчивых архитектур. Дополнительную информацию можно найти
в описании фреймворка AWS Well-Architected Framework на странице https://
docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-
pillar.html.
Зеленые ИТ и их влияние на затраты 399
Представьте, что вы планируете развернуть новое веб-приложение, которое
ожидает получать переменный уровень трафика. Чтобы оптимизировать затраты
и следовать принципам зеленых ИТ, можно действовать по следующей схеме.
1. Планирование и проектирование.
Компания решает использовать AWS ввиду приверженности платформы
к экологичности и энергоэкономичности инфраструктуры.
Принимается решение об использовании бессерверной архитектуры с ис-
пользованием AWS Lambda для вычислений, что позволяет выполнять код
без выделения серверов или управления ими. Такой выбор экономичен
и экологичен, поскольку он устраняет необходимость в недозагружаемых
серверах.
2. Реализация.
Фронтенд веб-приложения размещается с использованием Amazon S3,
а глобальный доступ к нему обеспечивается через Amazon CloudFront.
Таким образом сокращается задержка и минимизируется энергия, необхо-
димая для обслуживания конечных пользователей за счет использования
энергоэкономичных дата-центров рядом с местонахождением пользова-
теля для поставки такого контента, как видео и графика.
Бэкенд приложения строится на базе AWS Lambda и Amazon Dynamo DB,
предоставляющих бессерверное решение для баз данных, автоматически
масштабируемое в соответствии с рабочей нагрузкой.
3. Оптимизация.
Для непрерывной интеграции и развертывания используются механизмы
AWS CodePipeline и AWS CodeBuild, что позволяет избежать затрат на
поддержание выделенных серверов сборки.
4. Мониторинг и управление.
AWS CloudWatch отслеживает производительность приложения и уро-
вень использования ресурсов, обеспечивая эффективную эксплуатацию.
Рекомендации AWS Trusted Advisor применяются для дальнейшей
оптимизации затрат и гарантируют, что компания использует ресурсы
максимально эффективно.
5. Управление затратами.
Компания использует AWS Budgets для назначения порогов затрат и вы-
дачи оповещений в случае, если затраты вскоре превысят бюджет. Опове-
щения позволяют своевременно скорректировать использование ресурсов.
Компания использует AWS Cost Explorer для анализа и понимания своих
расходов на AWS и использования ресурсов по времени. Таким образом
обеспечивается непрерывная оптимизация затрат.
400 Глава 10. Оптимизация затрат
Компания успешно развертывает свое веб-приложение в масштабируемой и эко-
номичной инфраструктуре с применением бессерверных сервисов AWS и средств
оптимизации ресурсов. Она сокращает свой углеродный след, используя энерго-
экономичную глобальную инфраструктуру AWS и потребляя вычислительные
мощности только там, где это необходимо, придерживаясь принципов зеленых
ИТ. Кроме того, модель сервисов AWS с оплатой по фактическому использова-
нию гарантирует, что оплачиваться будут только реально потребляемые ресурсы,
что обеспечивает как оптимизацию как затрат, так и энергосбережение.
AWS может упростить практику применения зеленых ИТ, позволяя развертывать
масштабируемые, высокопроизводительные веб-приложения с учетом влияния
на окружающую среду и затраты на эксплуатацию. Бессерверные предложения
AWS и эффективное управление ресурсами сочетаются с целями компании по
оптимизации затрат и устойчивости.
Итоги
Оптимизация затрат — это непрерывный процесс, который начинается
с первых дней жизни приложения, от доказательства жизнеспособности
концепции (РоС) и до реализации и обслуживания продукта после выпуска.
Необходимо непрерывно анализировать архитектуру и возможности для со-
кращения затрат.
В этой главе вы узнали о принципах проектирования для оптимизации за-
трат. Прежде чем принимать решения о покупке, рассмотрите совокупную
стоимость владения для всего жизненного цикла программного продукта или
оборудования. Планирование бюджета и отслеживание прогнозов помогает
поддерживать оптимизацию затрат. Всегда отслеживайте свои затраты и ищите
возможности их непрерывной оптимизации за счет управления потребностя-
ми, но так, чтобы это не отражалось на взаимодействии с пользователями или
бизнес-ценности.
Вы узнали о методах оптимизации затрат, включая сокращение архитектурной
сложности за счет упрощения корпоративной архитектуры и создания стандарта,
которому могут следовать все остальные. Желательно избегать дублирования
в архитектуре, выявляя и консолидируя простаивающие и дублирующиеся
ресурсы, а также обсуждать с вендорами предоставление скидки за объем. При-
меняйте стандартизацию в масштабах организации, чтобы ограничить приобре-
тение ресурсов, и разработайте стандартную архитектуру. Отслеживание данных
фактических затрат в сравнении с бюджетом и прогнозом поможет активно
влиять на текущую ситуацию. Вы узнали об отчетах и оповещениях, которые
помогают контролировать затраты. Также была рассмотрена оптимизация затрат
в облаке, которая обеспечивает дополнительные возможности для оптимизации.
Устойчивость — еще один важный параметр современных рабочих нагрузок
Итоги 401
в ИТ; вы узнали, как на затраты влияют зеленые ИТ. Также была рассмотрена
тема создания и отслеживания потребления зеленых ИТ в AWS.
Автоматизация и адаптивность — важные факторы, повышающие эффективность
использования ресурсов, и методология DevOps позволяет в значительной мере
автоматизировать работу. В следующей главе вы узнаете о компонентах DevOps
и стратегиях эффективного развертывания рабочей нагрузки с максимальной
автоматизацией.
ГЛАВА 11
DEVOPS И ФРЕЙМВОРК
АРХИТЕКТУРЫ РЕШЕНИЙ
В предыдущей главе были рассмотрены методы создания архитектуры с учетом
затрат и методы непрерывной оптимизации затрат без ущерба для производи-
тельности. Автоматизация и совместная работа команд играют ключевую роль
в разработке надежных приложений и снижении затрат. В этой главе рассма-
тривается DevOps — методология, способствующая совместной работе команд
разработки (Dev) и эксплуатации (Ops) одновременно с автоматизацией про-
цессов развертывания и мониторинга приложения.
В традиционных средах команда разработки и команда ИТ-эксплуатации ра-
ботают изолированно. Команда разработки собирает требования у владельцев
бизнеса и разрабатывает приложения. Системные администраторы отвечают
исключительно за эксплуатацию и соблюдение требований к доступности. Эти
команды обычно мало взаимодействуют в течение жизненного цикла разработки,
и редко понимают процессы и потребности друг друга.
Каждая команда использует свои инструменты, процессы и решения с избы-
точностью, что иногда приводит к конфликтам. Например, команды разработки
и контроля качества (QA) могут протестировать сборку с конкретным патчем
операционной системы. Однако команда эксплуатации развертывает ту же
сборку в продакшен-среде на другой версии ОС, что приводит к проблемам
и нарушению сроков.
DevOps — методология, поощряющая сотрудничество и координацию между
командами разработки и эксплуатации для непрерывной поставки продуктов
или сервисов. Этот подход особенно эффективен в организациях, где команды
зависят от разных приложений, инструментов, технологий, платформ, баз дан-
ных, устройств и т. д. в процессе разработки или поставки продукта либо сервиса.
Хотя существуют разные подходы к культуре DevOps, все они направлены на
достижение общей цели. Суть DevOps заключается в поставке продукта или
сервиса в кратчайшие сроки за счет повышения операционного совершенства
через разделение обязанностей.
Знакомство с DevOps 403
Безопасность входит в число главных приоритетов любого приложения, а инци-
денты безопасности могут иметь серьезные последствия для бизнеса. Несмотря
на это, на этапе развертывания безопасность рассматривается как следствие про-
цесса развертывания и отдельная обязанность, за которую отвечает реактивно
команда безопасности (Sec).
Внедрение безопасности как критически важного параметра DevOps может до-
стигаться реализацией методологии DevSecOps. Суть DevSecOps заключается
в интеграции безопасности в начале и на протяжении всего жизненного цикла
разработки ПО, что помогает преодолеть изоляцию и наладить совместную
работу между командами разработки, эксплуатации и безопасности. DevSecOps
помогает добиваться результатов без ущерба для качества, надежности, стабиль-
ности, устойчивости или безопасности.
В этой главе рассматриваются следующие темы.
• Знакомство с DevOps.
• Компоненты DevOps.
• Непрерывная интеграция / непрерывное развертывание (CI/CD).
• DevSecOps в безопасности.
• Объединение DevSecOps с CI/CD.
• Реализация стратегии CD.
• Реализация непрерывного тестирования в пайплайне CI/CD.
• Использование инструментов DevOps для CI/CD.
• Реализация лучших практик DevOps.
• Построение DevOps и DevSecOps в облаке.
К концу этой главы вы узнаете о важности DevOps для развертывания, тести-
рования и безопасности приложений. Кроме того, вы познакомитесь с лучшими
практиками DevOps и DevSecOps, а также с другими инструментами и методами
реализации.
Знакомство с DevOps
В DevOps команды разработки и эксплуатации совместно работают на этапах
сборки и развертывания жизненного цикла программного продукта, разделяя
ответственность и предоставляя непрерывную обратную связь. Сборки про-
граммного продукта часто тестируются на этапе сборки в средах, сходных с про-
дакшен-средой, что делает возможным раннее выявление дефектов.
Методология DevOps сочетает культуру и практики. Она требует, чтобы
организация изменила свою культуру, ломая барьеры между всеми команда-
ми в жизненном цикле разработки и поставки продукта. DevOps не сводится
к разработке и эксплуатации: методология задействует всю организацию,
включая руководство, владельцев бизнеса/приложений, инженеров по кон-
тролю качества (QA), релиз-менеджеров, команду эксплуатации и системных
администраторов.
404 Глава 11. DevOps и фреймворк архитектуры решений
Скорость позволяет организациям опережать конкурентов и быстро отвечать
на требования пользователей. Хорошие практики DevOps поощряют более эф-
фективную совместную работу инженеров-разработчиков с профессионалами
в области эксплуатации. Результатом становится улучшение совместной работы
и коммуникации, что сокращает время вывода продуктов на рынок, повышает
надежность выпуска, качество кода и поддержки.
Иногда выясняется, что разработкой и эксплуатацией приложения занимается
одна и та же команда инженеров на протяжении всего жизненного цикла при-
ложения. Такая команда должна иметь набор навыков, не ограниченных одной
функцией. Команды тестирования и безопасности также могут более тесно со-
трудничать с командами разработки и эксплуатации с первых дней работы над
приложением до его запуска.
Разработчики получают выгоду от обратной связи, предоставляемой командами
эксплуатации, и создают стратегии тестирования и развертывания. Системным
администраторам не приходится реализовывать дефектные или не прошедшие
тестирование продукты в продакшен-средах, поскольку они участвуют в создании
этих продуктов. Так как все ключевые участники жизненного цикла разработки
сотрудничают друг с другом, они также могут оценить инструменты, которые
планируется использовать на каждом этапе процесса, проверить совместимость
между устройствами и определить, могут ли какие-либо инструменты совместно
использоваться разными командами.
DevOps набирает популярность как предпочтительная культура эксплуатации,
особенно в организациях, использующих облачные технологии или распределен-
ные вычисления. Рассмотрим некоторые преимущества DevOps и разберемся,
почему эта методология важна для рабочей нагрузки приложения.
Преимущества DevOps
Целью DevOps является модель непрерывной интеграции / непрерывного раз-
вертывания (CI/CD), которая может использоваться для обеспечения повто-
ряемости, надежности, стабильности, устойчивости и безопасности жизненного
цикла разработки. Эти характеристики модели помогают улучшить опера-
ционную эффективность. Для достижения этой цели команды сотрудничают
и участвуют в процессе разработки и поставки. Все члены технических команд
должны иметь опыт использования процессов и инструментов, задействованных
в пайплайне разработки.
Сложившийся процесс DevOps имеет ряд преимуществ, представленных на
рис. 11.1.
Вот более подробный разбор преимуществ DevOps.
• Скорость: ускоренный выпуск новой функциональности продукта помогает
адаптироваться к меняющимся бизнес-потребностям клиентов и расширить
Знакомство с DevOps 405
долю рынка. Модель DevOps позволяет организациям быстрее добиться
результатов.
• Быстрая поставка: процессы DevOps способствуют повышению эффектив-
ности за счет автоматизации сквозных пайплайнов, от сборки кода до развер-
тывания и запуска рабочей версии. Быстрая поставка позволяет оперативнее
внедрять инновации, а ускорение выпуска исправлений ошибок и новой
функциональности дает возможность получить конкурентное преимущество.
• Надежность: процессы DevOps предоставляют проверки для обеспечения
качества продукта и безопасности быстрых обновлений приложения. Такие
практики DevOps, как CI и CD, внедряют автоматизацию тестирования
и проверки безопасности, улучшая опыт взаимодействий с конечным поль-
зователем.
• Масштабируемость: методология DevOps помогает масштабировать инфра-
структуру и приложение под конкретные потребности за счет повсеместного
применения автоматизации.
• Сотрудничество: модель DevOps формирует культуру владения, где команды
учитывают последствия своих действий. Команды разработки и эксплуатации
работают совместно по модели разделяемой ответственности. Сотрудничество
упрощает процессы и повышает эффективность.
• Безопасность: в адаптивной среде частые изменения требуют строгих про-
верок безопасности. Модель DevOps автоматизирует лучшие практики
безопасности и комплаенса, обеспечивает их мониторинг и автоматизацию
исправлений.
Сотрудничество
Безопасность
Масштабируемость
Надежность
Преимущества DevOps
Скорость
Быстрая поставка
Рис. 11.1. Преимущества DevOps
406 Глава 11. DevOps и фреймворк архитектуры решений
Команды принимают на себя полную ответственность за сервисы, которые они
создают, часто за пределами традиционных рамок своих ролей, и учатся мыслить
с точки зрения клиента для решения любых проблем.
Рассмотрим основные составляющие процессов DevOps.
Составляющие DevOps
Инструменты и автоматизация DevOps сводят воедино разработку и системные
операции. Ниже перечислены ключевые компоненты практики DevOps:
• CI/CD;
• непрерывный мониторинг и улучшения;
• инфраструктура как код;
• управление конфигурацией.
Общее для всех элементов — их автоматизация. В автоматизации могут исполь-
зоваться скрипты, шаблоны и другие инструменты. В развитой среде DevOps
управление инфраструктурой осуществляется в виде кода. Автоматизация позво-
ляет командам DevOps быстро создавать и настраивать тестовые и рабочие среды.
Рассмотрим теперь более подробно каждую составляющую.
Непрерывная интеграция / непрерывное развертывание
При непрерывной интеграции (CI) разработчики выполняют частые коммиты
кода в репозитории. Код регулярно собирается, и каждая сборка тестируется
при помощи автоматизированных модульных и интеграционных тестов. При
непрерывном развертывании (CD) процесс идет дальше: происходит частое
развертывание кода на продакшен. Сборки развертываются в тестовых средах
и тестируются с использованием автоматизированных (и, возможно, ручных)
тестов. Успешные сборки проходят тесты и развертываются в промежуточных
(стейдж) или продакшен-средах.
На рис. 11.2 показано влияние CI и CD на жизненный цикл разработки про-
граммного продукта.
Как показано на диаграмме, CI относится к стадиям сборки и модульного тести-
рования жизненного цикла разработки продукта. Каждое обновление, сохраняе-
мое в репозитории кода, инициирует автоматизированную сборку и тестирова-
ние. CD является важнейшим следствием CI, расширяющим эту практику до
развертывания сборки в продакшен-среде. В рамках CI/CD над кодом работают
множество специалистов. Все они должны использовать последнюю работо-
способную сборку. В репозиториях кода хранятся разные версии кода, а код
делается доступным для команды. Вы извлекаете код из репозитория, вносите
изменения, пишете новый код в своей локальной копии, компилируете и тести-
руете его и с высокой частотой сохраняете в основном репозитории. В CI/CD
такие этапы жизненного цикла разработки, как написание кода, сборка, разверты-
вание и тестирование, автоматизируются с использованием пайплайна DevOps.
Составляющие DevOps 407
Непрерывное
развертывание
Интеграционное
развертывание
и управление
Менеджмент
Непрерывная
интеграция
Рис. 11.2. CI/CD
CI автоматизирует большую часть процесса выпуска ПО. Эта практика подразу-
мевает создание автоматизированного процесса создания, тестирования, а затем
развертывания обновления в промежуточной среде. Однако разработчик должен
инициировать завершающее развертывание в живой продакшен-среде, которая
не автоматизирована. CD расширяет практику CI и включает развертывание
всех изменений кода в среде тестирования и/или продакшен-среде после этапа
сборки. При правильной реализации CD у разработчиков всегда имеется про-
тестированная и готовая к развертыванию сборка.
На рис. 11.3 представлено все, что можно автоматизировать в приложении, от
сохранения кода в репозитории до пайплайна развертывания. На нем изображен
сквозной поток от сборки до продакшен-среды, где разработчик сохраняет из-
менения кода в репозитории, а сервер CI эти изменения извлекает. Сервер CI
инициирует сборку для создания пакета развертывания с новыми двоичными
файлами приложения и соответствующими зависимостями. Новые двоичные
файлы развертываются в целевой среде разработки или тестирования. Они также
сохраняются в репозитории артефактов для безопасного хранения с контролем
версий.
408 Глава 11. DevOps и фреймворк архитектуры решений
---------------►
Конфигурация
зависимостей
Успешная сборка/отправка отчета об
ошибке разработчику
Рис. 11.3. CI/CD для DevOps
Репозиторий артефактов
Сервер развертывания среды
тестирования/разработки/
эксплуатации
Надежный пайплайн CD также автоматизирует предоставление инфраструктуры
для сред тестирования и продакшен и делает возможным мониторинг и управле-
ние этими средами. CD не означает, что каждое изменение, сохраняемое разра-
ботчиком, попадет в рабочую версию, — а лишь то, что каждое изменение готово
к этому. Когда изменения тестируются в промежуточной среде, процесс ручного
утверждения запускает и дает «зеленый свет» для развертывания на продакшен.
Таким образом, в практике CD развертывание на продакшен становится бизнес-
решением и автоматизируется с использованием инструментов.
Непрерывный мониторинг и улучшения
Непрерывный мониторинг позволяет оценить, как производительность при-
ложений и инфраструктуры влияет на клиента. Анализ данных и журналов
помогает понять, как изменения в коде отразятся на пользователях.
Активный мониторинг исключительно важен в эпоху сервисов, работающих
в режиме 24/7, и постоянных обновлений в приложениях и инфраструктуре.
Составляющие DevOps 409
Вы можете организовать активный мониторинг сервисов, настраивая оповеще-
ния и выполняя анализ в реальном времени. Существуют различные метрики,
которые могут отслеживаться для контроля и улучшения практики DevOps.
Примеры DevOps метрик.
• Объем изменений: количество разработанных пользовательских историй,
количество строк нового кода, количество исправленных ошибок.
• Частота развертывания: насколько часто команда развертывает приложение.
В общем случае метрика должна оставаться стабильной или демонстрировать
восходящую тенденцию.
• Время от разработки до развертывания: анализ периода времени от начала
цикла разработки до завершения развертывания поможет выявить неэффек-
тивности на промежуточных этапах цикла выпуска.
• Процент неудачных развертываний: процент неудачных развертываний,
включая количество развертываний, приводящих к нарушению работо-
способности, должен быть низким. Эту метрику следует рассматривать
в сочетании с объемом изменений. Если объем изменений невелик, а коли-
чество развертываний со сбоем высоко, проведите анализ потенциальных
точек сбоя.
• Доступность: отслеживайте, какое количество выпусков вызвало сбои, ко-
торые могли привести к нарушению соглашений об уровне обслуживания
(SLA). Каково среднее время неработоспособности приложения?
• Объем жалоб клиентов: количество тикетов, открытых клиентами, характе-
ризует качество приложения.
• Процентное изменение количества пользователей: количество новых
пользователей, регистрирующихся для использования приложения, и со-
путствующее повышение трафика могут помочь при масштабировании
инфраструктуры в соответствии с рабочей нагрузкой.
После развертывания сборки в рабочей среде необходимо вести мониторинг
эффективности приложения. Рассмотрим практику «инфраструктура как код»
(1аС) более подробно.
Инфраструктура как код
Приобретение инфраструктуры, управление ею и даже списание устаревшей —
процессы, требующие участия человека. Более того, повторные попытки руч-
ного создания и изменения сред могут приводить к ошибкам. Чем бы человек
ни руководствовался, прошлым опытом или хорошо документированными
инструкциями, по статистике он склонен ошибаться.
Задачу создания готовой среды можно автоматизировать. Автоматизация за-
дач может упростить выполнение однообразных операций и позволит создать
значительную ценность без приложения особых усилий.
410 Глава 11. DevOps и фреймворк архитектуры решений
В рамках 1аС инфраструктура может определяться с помощью шаблонов.
Один шаблон может описывать как часть среды, так и всю среду. Что еще
важнее, шаблон может использоваться повторно для того, чтобы создать ту
же среду заново.
Создание и управление инфраструктурой в 1аС осуществляется в форме кода.
Модель 1аС упрощает взаимодействие с инфраструктурой на программном уров-
не в масштабе и помогает избежать человеческих ошибок за счет автоматизации
конфигурирования ресурсов. При таком подходе можно работать с инфраструк-
турой так же, как с кодом, и использовать инструменты для работы с кодом. Так
как управление инфраструктурой также осуществляется из кода, приложение
может развертываться с использованием стандартизированного метода, а любые
исправления и версии могут обновляться без ошибок.
Среди популярных скриптовых инструментов 1аС можно выделить Ansible,
Terraform, Azure Resource Manager, Google Cloud Deployment Manager, Chef,
Puppet, AWS Cloud Development Kit (CDK) и AWS CloudFormation.
Ниже приведен фрагмент кода сервиса AWS CloudFormation, предоставляющего
поддержку 1аС для автоматизации инфраструктур на облачной платформе AWS.
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Create an S3 Storage with a parameter to choose own bucket name.'
Parameters:
S3NameParam:
Type: String
Default: 'architect-book-storage'
Description: 'Enter the S3 Bucket Name'
MinLength: '5'
MaxLength: '30'
Resources:
Bucket:
Type: 'AWS::S3::Bucket'
DeletionPolicy: Retain
Properties:
AccessControl: Private
BucketName:
Ref: S3NameParam
Tags:
- Key: 'Name'
Value: 'MyBucket'
Outputs:
BucketName:
Description: 'BucketName'
Value:
Ref: S3NameParam
Составляющие DevOps 411
Этот фрагмент создает хранилище объектов Amazon S3, и пользователь может
выбрать имя хранилища, как показано ниже.
ClaudFarnuuon Staclts > Crtatf stack
* create suck
Specify stack details!
5wpl
@ Specify stack deuib
J'4» 1
ф Configure sa«9piK«
Step*
Яомст
Stack name
Stack пик
l ШиВ0ИАПЯИ£Т-ЬМ1с-ЯЙД5е
SiMk штейн tn<b4c tcHnCbz and aM daks|-k
Parameters
Psnru<< cis undefined in your template and aUow to -лр^с отоn values wff" ii orate iujta! J Чиг.
SINama Pinffi
Emh* ilwCI BuAhHwtm
3':ГН:К1-Ь*Л‘^УЧЖ
CanteL
PrOvlOUt
Рис. 11.4. laC с использованием AWS CloudFormation
После выполнения кода создается бакет Amazon S3, который можно увидеть
на вкладке Resources.
S оluticnsArc h itect-b ос k-storage
Delete D C Updata 3 C Stack actions ▼ 3 Create stack ▼
Stack info Events [ Resources ]
Outputs Parameters
Template
Change sets
Resources (1)
Ct Seartf) resources
Logical ID a ] Physical ID v ] туре
v | Status
Bucket Aws::S3::0ucket © crfate.complete
storage И
Рис. 11.5. Автоматизированное создание хранилища объектов AWS S3
с использованием AWS CloudFormation
412 Глава 11. DevOps и фреймворк архитектуры решений
Разные команды могут использовать приведенный код для создания хранилища
Amazon S3 любого объема. Так как данные чрезвычайно важны, администратор
выбрал добавление бакета “DeletionPolicy”: "Retain”; это гарантирует, что
хранилище не будет удалено при отключении инфраструктуры, а данные оста-
нутся в безопасности.
Теперь вы знаете, как реализовать стандартизацию и согласованность данных с ис-
пользованием методологии 1аС. Управление конфихурацией — еще один жизненно
важный аспект процесса DevOps, который мы рассмотрим в следующем разделе.
Управление конфигурацией
Управление конфигурацией (CM, configuration management) — это процесс
автоматизированной стандартизации конфигураций ресурсов во всей инфра-
структуре и приложениях. Такие инструменты СМ, как Chef, Puppet и Ansible,
помогут управлять 1аС и автоматизировать большинство задач системного
администрирования, включая предоставление ИТ-ресурсов, настройку их кон-
фигурации и управление ими.
Автоматизируя и стандартизируя конфигурации ресурсов на этапах разработки,
сборки, тестирования и развертывания, можно обеспечить целостность конфи-
гурации и избавиться от ошибок, обусловленных неверной конфигурацией. СМ
также может повысить эффективность эксплуатации, позволяя автоматически
развернуть одну конфигурацию на сотнях серверов простым нажатием кнопки.
СМ также может использоваться для развертывания изменений в koi 1фи гу рациях.
Хотя настройки системной конфигурации также могут храниться в реестре или
базах данных, приложение СМ наряду с хранением позволяет организовать
управление версиями. СМ также представляет возможность отслеживания
и аудита изменений конфигурации. При необходимости даже можно поддер-
живать несколько версий конфигурации для разных версий продукта.
Инструменты СМ включают машину-контроллер, управляющую серверными
узлами. Например, основное приложение Chef устанавливается на машине-
контроллере, а на каждом сервере, которым надо управлять, устанавливается
клиентское приложение-агент. Puppet работает по аналогичной схеме с цен-
трализованным сервером. Ansible же использует децентрализованный под-
ход, который не требует установки агентского программного обеспечения на
серверных узлах.
В табл. 11.1 приведено обобщенное сравнение популярных инструментов управ-
ления конфигурацией.
Инструменты СМ предоставляют специализированный язык и набор функций
для автоматизации. Освоение некоторых инструментов требует на начальной
стадии значительных усилий. В AWS имеются платформа Ops Works для
управления Chef и Puppet в облаке, а также различные средства автоматизации
управления ИТ-инфраструктурой.
Составляющие DevOps 413
Таблица 11.1. Сравнение популярных инструментов СМ
Ansible Puppet Chef
Механизм Машина-контрол- лер применяет из- менения к серверам с использованием SSH (Secure Shell) Ведущий узел синхро- низирует изменения с узлами Puppet Рабочая станция Chef ищет изме- нения на серверах Chef и отправляет их узлу Chef
Архитектура Любой сервер мо- жет быть контрол- лером Централизованный контроль со стороны ведущего узла Puppet Централизованный контроль со стороны сервера Chef.
Скриптовый язык YAML Специализированный на базе Ruby Ruby
Терминоло- гия скриптов Playbook («сценарий») и roles («роли») Manifests и modules Recipes («рецепты») и cookbooks(«пова- ренные книги»)
Выполнение тестов Последовательный порядок Произвольный по- рядок П о сл ед о в ател ь н ы й порядок
Layers
Apps
Instances
A layer is Я blueprint for Я sst of instances. It
specifies the instances resources, installed
packages. profilers and socurtly groups.
Add a layer
An instance represents a server. It Gan belong to
one or more layers, that determine the instance's
resources and configиration.
Add an instance or register a server
Deployments and Commands
An app represents crdn stored n a герсгмГОгу
that you want to run on application serve:
instances.
Add an app
You can deploy the code from your repo sitcry tn
the appcprvte carver or run cynmanas on
some o< »Л' 4tarc»J in ул if steck.
Deploy an app or run a command
Resources
Monitoring
The Resourcei peg» ыз-imi . you to uw any «4
your account's Elastic l₽ addresses, volumes, or
RDS instances in your stack.
Register паошсм
aw$ Opsworks iftr. Amazon clpudwatthlo
provide thJrtean oustor* тйпсз ml*? dntГр J
monitoring for each instance in the stack.
Show morittorine
Permissions
Tags СЕЭ
Permissions specify how imported 1AM users
can access this stack. To Import users, go to the
Users page.
Manage permissions
You can specify lags to apply to resources in th®
Stack. Tags can help you identify resources in
cost allocation reports.
Menage stack lags
Рис. 11.6. Функциональность сервисов AWS OpsWorks
для управления Chef и Puppet
414
Глава 11. DevOps и фреймворк архитектуры решений
Безопасность стала приоритетом для любой организации, так что полную
автоматизацию безопасности можно считать насущной необходимостью. Ор-
ганизации переходят на жесткие реализации и мониторинг безопасности для
предотвращения человеческих ошибок, используя процесс DevOps, известный
под названием DevSecOps (сокращение от Development, Security, Operations,
то есть «разработка, безопасность, эксплуатация»).
DevSecOps
Современные разработчики уделяют безопасности гораздо больше внимания,
чем ранее. Зачастую безопасность оказывается единственным способом завое-
вать доверие клиента. Суть DevSecOps заключается в автоматизации и мас-
штабируемой реализации безопасности. Команда разработки постоянно вносит
изменения, а команда DevOps публикует их в продакшен-среде (изменения
часто ориентированы на клиента). DevSecOps обеспечивает безопасность при-
ложения в общем процессе.
Внедрение DevSecOps не сводится к аудиту кода или артефактов CI/CD. Орга-
низации должны реализовать DevSecOps для обеспечения скорости и гибкости,
но не за счет проверок безопасности, которые замедляют процесс разработки
и развертывания. Эффективность автоматизации проявляется в повышении
гибкости выпуска новой функциональности одновременно с реализацией необхо-
димых мер безопасности. Подход DevSecOps приводит к тому, что безопасность
становится неотъемлемой частью приложения; она не применяется «задним
числом». Практика DevOps направлена на ускорение жизненного цикла запуска
продукта, a DevSecOps обеспечивает проверку всех структурных элементов без
замедления жизненного цикла.
Чтобы внедрить подход DevSecOps в организации, для начала сформируйте на-
дежный фундамент DevOps в среде разработки, так как безопасность должна быть
ответственностью всех участников. Лучше внедрить безопасность в архитектуру
с самого начала, чтобы наладить совместную работу команд разработки и безопас-
ности. Автоматизируйте непрерывное тестирование безопасности и встройте его
в пайплайн CI/CD, чтобы избежать любых слабых мест в области безопасности.
Чтобы своевременно обнаруживать любые нарушения безопасности, расширьте
мониторинг и включите в него контроль безопасности и комплаенса, в реальном
времени отслеживая отклонения от первоначального дизайна. Мониторинг
должен включать механизм оповещений, автоматизированного исправления
и исключение ресурсов, нарушающих требования комплаенса.
Практика DevSecOps должна поддерживать темп инноваций, который соответ-
ствует темпу автоматизации безопасности. Масштабируемая инфраструктура
требует столь же масштабируемых механизмов защиты, включая автомати-
зированное реагирование на инциденты, непрерывный контроль комплаенса
и автоматическую валидацию безопасности.
Объединение DevSecOps и CI/CD 415
Объединение DevSecOps и CI/CD
Практика DevSecOps должна внедряться на каждом этапе пайплайна CI/CD.
Чтобы обеспечить его безопасность, DevSecOps реализует управление доступом
и ролями, назначенными каждому серверу, и следит, чтобы серверы сборки (на-
пример, Jenkins) были защищены от любых уязвимостей безопасности. Также
необходимо позаботиться о проверке всех артефактов и анализе кода.
Следует подготовиться к реагированию на инциденты, автоматизируя непре-
рывную проверку соответствия требованиям и принятие мер восстановления.
Например, если организация должна соответствовать стандарту PCI-DSS
(Payment Card Industry Data Security Standard), необходимо настроить автомати-
зированные инструменты для постоянного мониторинга, обеспечить контроль за
обработкой, передачей и хранением данных кредитных карт и автоматизировать
проверку соблюдения всех требований PCI-DSS.
На рис. 11.7 представлены стадии тестирования границ безопасности и обна-
ружения проблем безопасности, а также как можно более ранней проверки
соответствия политикам.
Сканирование секретов
Тегирование артефактов
безопасности
Тестирование на соответствие
стандартам безопасности
Развертывание и регистрация
компонентов безопасности
Обеспечение
Мониторинг
Мониторинг стандартов
безопасности
Рис. 11.7. DevSecOps и CI/CD
416
Глава 11. DevOps и фреймворк архитектуры решений
Как показано на диаграмме, в каждой точке интеграции можно выявить раз-
личные проблемы.
• На этапе написания кода проводится сканирование всего кода для проверки,
что он не содержит никаких секретов или ключей доступа.
• На этапе сборки включаются все артефакты безопасности (например, ключи
шифрования и маркеры доступа), которые помечаются тегами для удобства
идентификации.
• На этапе тестирования проводится сканирование конфигурации для про-
верки соблюдения всех стандартов безопасности.
• На этапах развертывания и обеспечения проверяется регистрация всех
компонентов безопасности. Вычисление контрольной суммы позволяет
убедиться, что файлы сборки не были изменены. Метод контрольных сумм
используется для определения подлинности полученных файлов. Операци-
онные системы предоставляют команду checksum для проверки файлов на
отсутствие изменений при передаче.
• На этапе мониторинга отслеживаются все стандарты безопасности, прово-
дится непрерывный автоматизированный аудит и проверки.
В пайплайны DevSecOps можно интегрировать различные инструменты для
идентификации уязвимостей безопасности на разных стадиях, а также для сбора
и накопления информации об обнаруженных уязвимостях.
Практика AST (application security testing, проверка безопасности приложения),
включающая использование инструментов для автоматизации тестирования,
анализа уязвимостей, а также генерации соответствующих отчетов, является
критически важным компонентом разработки приложений. Процесс AST можно
разбить на четыре категории.
• Композиционный анализ программного продукта (SCA, software composite
analysis): SCA оценивает уровень безопасности программного продукта с от-
крытым исходным кодом, соответствие лицензии и качество кода в кодовой
базе. SCA старается обнаружить уязвимости в зависимостях проекта. По-
пулярные инструменты SCA — О WASP Dependency-Check, Synopsys Black
Duck, WhiteSource, Synk и GitLab.
• Статическое тестирование безопасности приложения (SAST, static
application security testing): SAST включает сканирование кода приложения
до компиляции. Оно предоставляет разработчикам немедленную обратную
связь в процессе написания кода, что позволяет исправлять ошибки до этапа
сборки. SAST относится к категории методов тестирования по принципу «бе-
лого ящика»: исходный код анализируется на предмет уязвимостей к атакам
на приложение. Ключевым преимуществом SAST является интеграция на
ранней стадии цикла DevOps, на этапе написания кода, так как эта практика
не требует ни функционирующего приложения, ни выполнения кода. Попу-
лярные инструменты SAST — SonarQube, PHPStan, Coverity, Synk, Appknox,
Klocwork, CodeScan и Checkmarx.
Реализация стратегии CD 417
• Динамическое тестирование безопасности приложения (DAST, dynamic
application security testing): DAST выявляет уязвимости безопасности, ими-
тируя внешние атаки на приложение во время его выполнения. DAST обра-
щается к приложению снаружи, проверяя внешние интерфейсы на наличие
уязвимостей. К числу инструментов DAST, также называемых средствами
тестирования безопасности по принципу «черного ящика» или сканерами
уязвимостей веб-приложения, относятся О WASP ZAP, Netsparker, Detectify
Deep Scan, StackHawk, Appknox, HCL AppScan, GitLab и Checkmarx.
• Интерактивное тестирование безопасности приложения (I AST, interactive
application security testing): I AST анализирует код на уязвимости безопас-
ности во время активного тестирования или использования приложения;
таким образом вы получаете информацию о проблемах в реальном време-
ни, не создавая задержек в пайплайне CI/CD. Инструменты IAST обычно
реализуются в средах QA наряду с автоматизированными функциональ-
ными тестами. Среди инструментов I AST заслуживают внимания GitLab,
Veracode, CxSAST, Burp Suite, Acunetix, Netsparker, InsightAppSec и HCL
AppScan.
Интеграция некоторых из упомянутых инструментов в пайплайн DevOps будет
рассмотрена в этой же главе позже, в разделе «Создание DevOps и DevSecOps».
Процесс DevSecOps CI/CD гарантирует, что код прошел проверку в соответствии
с корпоративной политикой безопасности. Это помогает избежать любых сбоев
инфраструктуры и приложения на этапе развертывания из-за несовместимых
настроек безопасности. DevSecOps поддерживает гибкость и обеспечивает без-
опасность в масштабе, не влияя на темп инноваций DevOps.
В следующем разделе рассматривается стратегия непрерывного развертывания
(CD) в пайплайне DevOps.
Реализация стратегии CD
CD обеспечивает бесшовную миграцию существующей версии приложения на
новую версию. Некоторые популярные методы реализации с применением CD:
• развертывание на месте (in-place deployment): обновляет приложение на
текущем сервере;
• скользящее (rolling) развертывание: постепенное развертывание новой
версии на существующем парке серверов;
• сине-зеленое (blue-green) развертывание: постепенная замена существую-
щего сервера новым сервером;
• красно-черное (red-black) развертывание: мгновенное переключение на
новый сервер с существующего сервера;
• неизменяемое (immutable) развертывание: совместный запуск нового на-
бора серверов.
Рассмотрим каждый из них более подробно.
418 Глава 11. DevOps и фреймворк архитектуры решений
Развертывание на месте
Развертывание на месте — метод запуска новой версии приложения на существую-
щем парке серверов. Обновление выполняется за один раз и требует некоторого
периода неработоспособности. Этот способ не подразумевает практически ника-
ких изменений инфраструктуры. Также не требуется обновлять существующие
записи DNS. Само развертывание выполняется относительно быстро. Если оно
завершается неудачей, то единственным способом восстановления является
повторное развертывание.
Простейший пример: вы заменяете существующую версию приложения (vl)
в инфраструктуре приложения новой версией (v2). Обновления обходятся
дешево и быстро развертываются.
Скользящее развертывание
При скользящем развертывании парк серверов делится на группы, чтобы
не выполнять обновление одновременно. В процессе развертывания старая
и новая версии работают в одном парке серверов, но в разных группах. Сколь-
зящее развертывание помогает обеспечить нулевое время простоя. Если раз-
вертывание новой версии завершится неудачей, то это отразится только на
одной группе серверов, а риск будет минимальным, потому что оставшаяся
часть парка все еще будет нормально работать. При скользящем развертыва-
нии время простоя нулевое, но само развертывание длится чуть дольше, чем
развертывание на месте.
Скользящее развертывание не только сокращает время простоя, улучшая
пользовательский опыт, но и не требует лишних затрат на дополнительное вы-
деление ресурсов. В отличие от сине-зеленого развертывания, которое требует
создания временного дубликата среды, скользящие развертывания обновляют
существующие ресурсы один за одним, избавляя от необходимости в лишней
инфраструктуре. Хотя время развертывания может немного увеличиться по
сравнению с развертыванием на месте, этот метод не приводит к лишним затра-
там из-за выделения дополнительных ресурсов, вследствие чего эта стратегия
эффективна для непрерывной поставки без последствий для бюджета.
Сине-зеленое развертывание
При сине-зеленом развертывании «синей» средой считается существующая ра-
бочая среда, обслуживающая живой трафик. Параллельно создается «зеленая»
среда, в целом идентичная синей, но с новой версией кода. Когда наступает время
развертывания, рабочий трафик направляется из синей среды в зеленую. Если
в зеленой среде возникнут проблемы, рабочий трафик будет перенаправлен из
зеленой в исходную синюю среду. Переключение DNS и замена групп автомас-
штабирования — два самых популярных метода изменения маршрутизации
трафика при сине-зеленом развертывании.
Реализация стратегии CD 419
При использовании политики автомасштабирования можно постепенно заменять
существующие экземпляры экземплярами с новой версией приложения, когда
возникнет необходимость в его масштабировании. Этот вариант лучше подходит
для малых выпусков и небольших изменений в коде. Другой вариант — при-
менение маршрутизации DNS — для сложной балансировки нагрузки между
разными версиями приложения.
Как показано на рис. 11.8, после создания рабочей среды, в которой размещается
новая версия приложения, можно использовать маршрут DNS для передачи
небольшой части трафика в новую среду.
Route 53
Маршрутизация DNS
Балансировщик Балансировщик
нагрузки приложения нагрузки приложения
Рис. 11.8. Постепенное переключение DNS при сине-зеленом развертывании
Протестируйте зеленую среду на части рабочего трафика. Если в среде возник-
нут проблемы с функциональностью, вы немедленно узнаете об этом и пере-
ключите трафик обратно, пока они не успели оказать значительное влияние на
пользователей. Продолжайте постепенно переключать трафик, тестируя способ-
ность зеленой среды обрабатывать нагрузку. Организуйте мониторинг зеленой
среды для выявления проблем, чтобы трафик можно было вернуть, тем самым
420 Глава 11. DevOps и фреймворк архитектуры решений
ограничивая радиус поражения. Наконец, когда все метрики будут стабильны,
переведите в резерв синюю среду и освободите ресурсы.
Сине-зеленое развертывание помогает обеспечить нулевое время простоя и упро-
щает откат изменений. Вы можете настроить время развертывания в соответствии
с вашими потребностями. Однако нулевой простой затратен, так как требует
создания двух идентичных рабочих сред: активной (синей) и бездействующей
(зеленой). Необходимость дублирования среды означает более высокие затраты
из-за дополнительных ресурсов. Тем не менее эти затраты часто оправдываются
пользой, которую они приносят в плане снижения рисков и непрерывности
взаимодействия с пользователями.
Красно-черное развертывание
Прежде чем поднимать новую версию системы в красно-черном развертывании,
проведите канареечное тестирование (canary testing). Оно заменяет 1 % существу-
ющей рабочей системы новейшей версией приложения и организует мониторинг
новой версии на предмет ошибок. Система считается готовой к развертыванию,
если канареечный тест пройден. Новая версия системы существует параллельно
со старой и готова к переключению. Исходная емкость новой системы задается
вручную на основании количества работающих экземпляров — оно устанавли-
вается в качестве желательной емкости новой группы автомасштабирования.
После того как новая система заработает, обе системы переходят в красное со-
стояние, но трафик принимает только текущая версия.
Затем система переключается с существующей версии на новую при помощи
сервиса DNS. С этого момента старая версия считается черной; она все еще
работает, но не получает трафик. Если в новой версии обнаружатся проблемы,
возврат к старой версии будет сведен к простому перенаправлению сервера DNS
на балансировщик нагрузки старой версии.
Красно-черное развертывание несколько отличается от сине-зеленого. В крас-
но-черной среде происходит мгновенное переключение DNS со старой версии
на новую (такая схема называется dark launch, или «тайный запуск»), тогда как
в сине-зеленом развертывании DNS постепенно наращивает трафик на новую
версию. Сине-зеленые и красно-черные развертывания могут объединяться,
чтобы обе версии программного продукта существовали одновременно. Исполь-
зуются два разных пути в коде, но только один из них активирован. Другой путь
активируется флагом включения функциональности. Такая схема развертыва-
ния может использоваться для бета-тестирования там, где включением новой
функциональности можно управлять явно.
Красно-черное развертывание, как и сине-зеленое, подразумевает запуск двух
одинаковых сред для обеспечения нулевого времени простоя и упрощения от-
ката изменений. Затраты в основном связаны с необходимостью дублирования
ресурсов на этапе развертывания. Необходимо поддерживать «красную» среду
Выбор стратегии развертывания: лучшие практики
421
(текущая версия) и «черную» (новая версия). Обе среды должны быть полно-
стью работоспособными, из-за чего требования к ресурсам в переходный период
фактически удваиваются — включая вычисления, хранилище и сетевые ресурсы.
Хотя этот подход значительно сокращает риски развертывания и обеспечивает
непрерывность взаимодействия с пользователями, дублирование среды при-
водит к увеличению затрат. Но так как дополнительные ресурсы необходимы
только на протяжении окна развертывания, эти затраты временные и их можно
рассматривать как вложения в стабильность и надежность.
Неизменяемое развертывание
Если приложение имеет неизвестные зависимости, то неизменяемое (immutable),
или «одноразовое» (disposable), обновление может быть более простым решени-
ем. Старую инфраструктуру приложения, которая неоднократно изменялась со
временем, становится все сложнее обновлять. Такой способ обновления более
типичен в неизменяемых инфраструктурах.
В новой версии развертывается новый набор экземпляров серверов, тогда как
старые экземпляры останавливаются. Для обновлений можно создать клони-
рованную среду при помощи таких сервисов развертывания, как Chef, Puppet,
Ansible и Terraform, или использовать их в сочетании с конфигурацией авто-
масштабирования для управления обновлениями.
Кроме времени простоя, при проектировании стратегии развертывания необхо-
димо учитывать затраты. Для расчета затрат определите количество экземпляров,
которое придется заменить, и частоту развертываний. Используйте оптимальный
подход к развертыванию с учетом требований к бюджету и времени простоя.
В этом разделе были рассмотрены разные стратегии CD, которые помогают
выпустить релиз эффективно и без проблем. В следующем разделе будут рас-
смотрены лучшие практики выбора типа развертывания.
Выбор стратегии развертывания:
лучшие практики
Выбор стратегии развертывания очень важен для успешных обновлений при-
ложения и непрерывного взаимодействия с пользователями. Ниже перечислены
критерии для выбора наиболее подходящей стратегии.
• Развертывание на месте идеально для сценариев, когда особенно важна про-
стота, а приложение относительно невелико или имеет ограниченную пользо-
вательскую базу. Например, оно будет уместно при обновлении внутренних
инструментов компании силами небольшой команды. При развертывании
на месте приложение обновляется на текущем сервере, но важно отметить,
что этот вариант может привести к простоям. Эта стратегия не подходит для
крупномасштабных приложений или когда требуется высокая доступность.
422 Глава 11. DevOps и фреймворк архитектуры решений
Еще один типичный пример — обновление маломасштабного веб-сервиса
с низким пользовательским трафиком за ночь. Важно подготовить стратегию
отката изменений на случай, если обновление не сможет восстановить пре-
дыдущую версию, и быстро минимизировать нарушения работоспособности.
• Скользящее развертывание подходит для приложений, которые требуют
минимального простоя, но не нуждаются в дополнительных ресурсах. При
скользящем развертывании приложение обновляется постепенно на суще-
ствующем парке серверов. Типичный пример — поэтапное развертывание
обновления на серверах интернет-магазина, когда лишь часть пользователей
может столкнуться с потенциальными проблемами. С другой стороны, этот
метод не подходит для приложений, которые не могут одновременно под-
держивать несколько версий. Чтобы решать проблемы по мере их возник-
новения, важно проводить непрерывный мониторинг производительности
приложения в процессе развертывания.
• Сине-зеленое развертывание оптимально для приложений, которым кри-
тически важно нулевое время простоя. Финансовая компания может ис-
пользовать эту стратегию для обновления своего клиентского приложения.
После того как зеленая среда будет тщательно протестирована и готова к ис-
пользованию, трафик переключится с синей среды на зеленую. Метод требует
двойного объема ресурсов, но обеспечивает непрерывность взаимодействия
с пользователями и возможность быстрого отката. При этом очень важно,
чтобы механизмы балансировки нагрузки и переключения DNS работали
надежно и стабильно.
• Красно-черное развертывание похоже на сине-зеленое, но ориентировано на
ускоренное переключение на новую версию. Оно особенно эффективно для
быстрого выпуска новых версий и часто используется в контейнеризованных
средах. Например, сервис потоковой передачи видео может развернуть новую
версию своей платформы по этой стратегии, чтобы новая функциональность
немедленно стала доступной для всех пользователей. Хотя этот вариант
обеспечивает быстрый выпуск и немедленное переключение, очень важно
тщательно протестировать новую версию, потому что откат подразумевает
возврат к старой среде.
• Неизменяемое развертывание обеспечивает согласованность и надежность,
особенно в облачных средах. При каждом развертывании создаются новые
серверы, что гарантирует предсказуемость и стабильность состояния. Такой
подход может быть полезным в приложениях со сложными зависимостями,
так как позволяет избежать «дрейфа конфигураций» (configuration drift),
встречающегося в долгоживущих средах. Эта стратегия требует эффектив-
ного управления инфраструктурными ресурсами, так как она подразумевает
выделение новых серверов и вывод в резерв старых при каждом выпуске.
В каждой из перечисленных стратегий важно оценивать такие факторы, как
сложность приложения, масштаб, пользовательская база и последствия потен-
циальных простоев.
Реализация непрерывного тестирования в пайплайне CI/CD 423
Кроме того, стратегия развертывания выбирается с учетом доступности ресур-
сов, затрат на инфраструктуру и важности приложения. Регулярное обновление
и корректировка развертывания в соответствии с технологическими и организа-
ционными изменениями также важны для поддержания эффективного процесса
развертывания.
Для поставки качественного продукта необходимо выполнять тестирование при-
ложения на каждом этапе, что часто требует значительных усилий. Пайплайн
DevOps может помочь автоматизировать тестирование и повысить качество
и частоту будущих выпусков. В следующем разделе рассматривается практика
непрерывного тестирования в пайплайне CI/CD.
Реализация непрерывного тестирования
в пайплайне CI/CD
DevOps играет ключевую роль для непрерывного изменения бизнес-сценариев
на основе обратной связи от клиентов, запросов новой функциональности или
изменения рыночных тенденций. Надежный пайплайн CI/CD гарантирует,
что больше функциональности / обратной связи будет реализовано за меньшее
время, а клиенты быстрее получат доступ к новой функциональности.
С частыми сохранениями кода в репозитории наличие грамотной стратегии
тестирования, интегрированной в пайплайн CI/CD, обеспечивает качественное
закрытие цикла обратной связи. Непрерывное тестирование играет важную
роль для балансировки пайплайна CI/CD. Быстро расширять функциональ-
ность продукта хорошо, но чтобы иметь уверенность в том, что функцио-
нальность соответствует стандартам качества, понадобится непрерывное
тестирование.
Модульные, или юнит-тесты, составляют основу тестовой стратегии. Обычно
они запускаются на машине разработчика, выполняются быстрее и обходятся
дешевле других тестов. Рекомендуется выделять под модульные тесты до 70 %
ресурсов на тестирование. Ошибки, обнаруженные на этой стадии, легко ис-
править.
Модульные тесты часто выполняются разработчиками, и готовый код разверты-
вается для интеграции и тестирования системы. Эти тесты требуют собственных
сред, а иногда и отдельных команд тестирования, что увеличивает затраты. Когда
команда убедится, что вся предполагаемая функциональность работает так, как
ожидалось, группа эксплуатации должна провести тесты производительности
и соответствия. Этим тестам необходимы среды, аналогичные продакшен-сре-
де, поэтому они обходятся дорого. Приемочному тестированию (UAT, User
Acceptance Testing) тоже понадобится реплика продакшен-среды, что также
приводит к повышению затрат.
424 Глава 11. DevOps и фреймворк архитектуры решений
Как показано на рис. 11.9, модульные тесты выполняются для тестирования из-
менений в коде / новой функциональности на этапе разработки. Тестирование
обычно проводит разработчик на своей машине после написания кода.
Также рекомендуется выполнять статический анализ кода при внесении изме-
нений и проверять покрытие кода, соответствие рекомендациям по оформлению
и т. д. Модульные тесты без зависимостей выполняются быстрее.
Непрерывная интеграция
Непрерывная доставка/развертывание
Модульное
тестирование
Интеграционное
и компонентное
тестирование
А/В-тестирование,
канареечное
тестирование
Системное тестирование,
тестирование
производительности,
UAT-тестирование
Рис. 11.9. Непрерывное тестирование в CI/CD
Этап сборки — первый тест интеграции между отдельными компонентами.
На этапе сборки также уместно протестировать, не нарушает ли код какую-
либо существующую функциональность, а кроме того, провести регрессионное
тестирование.
Промежуточная (стейдж) среда является зеркальной копией продакшен-среды.
На этой стадии выполняется сквозное тестирование системы (здесь достаточно
подробно тестируются UI, логика бэкенда и API). Тесты производительности
проверяют производительность приложения при конкретной рабочей нагрузке.
К тестам производительности относятся нагрузочные и стрессовые тесты.
На этой стадии также выполняется UAT-тестирование как часть подготовки
к развертыванию на продакшен. Тестирование соответствия выполняется для
проверки соответствия отраслевым нормативам.
Допустим, надо интегрировать непрерывное тестирование в пайплайн С1/
CD, чтобы проверить, как работает персонализация видео на стриминговой
интернет-платформе. Когда команда разработки сохраняет изменения в коде,
инструмент CI (например, Jenkins) автоматически инициирует процесс сбор-
ки и проводит серию автоматизированных тестов. В частности, выполняются
модульные тесты для проверки отдельных компонентов функции персонали-
зации, интеграционные тесты для проверки совместимости с существующими
компонентами системы, а также UI-тесты, проверяющие взаимодействие с поль-
зователями. Тесты производительности особенно важны в этом сценарии — они
проверяют, что новая функциональность не ухудшает качества стриминга. Если
во время проведения тестов возникают проблемы, пайплайн останавливается,
чтобы разработчики внесли необходимые исправления; это гарантирует, что
на следующую стадию пройдет только тщательно проверенный код. После
Реализация непрерывного тестирования в пайплайне CI/CD 425
прохождения автоматизированного тестирования функциональность перехо-
дит в стейдж-среду, которая имитирует условия продакшен, для дальнейшего
тестирования и проверки. Дополнительный уровень проверки гарантирует, что
функциональность будет хорошо работать в разных сценариях и вариантах пове-
дения пользователя во время приемочного тестирования перед развертыванием.
А/В-тестирование
Зачастую при разработке программного продукта бывает неочевидно, какая
реализация той или иной функциональности окажется наиболее успешной. От-
вету на этот вопрос посвящена целая научная дисциплина — человеко-машин-
ное взаимодействие (HCI, human/computer interface). И хотя у UI-экспертов
имеются рекомендации, упрощающие проектирование удобных интерфейсов,
лучший вариант дизайна часто удается определить только одним способом:
представить его пользователям и посмотреть, смогут ли они с его помощью
решать свои задачи.
Такие стратегии, как А/В-тестирование или канареечное тестирование, прове-
ряют новую рабочую версию приложения. При A/В-тестировании новая версия
приложения развертывается на небольшой части рабочих серверов, после чего
анализируется обратная связь от пользователей. Постепенно в зависимости от
того, насколько хорошо пользователи принимают новое приложение, разверты-
вание расширяется вплоть до охвата всех рабочих серверов.
Как показано на рис. 11.10, в методологии А/В-тестирования две или более
версии функциональности предлагаются разным группам пользователей. Да-
лее собираются подробные метрики использования каждой реализации, a UI-
инженеры изучают собранные данные, чтобы определить, какую реализацию
выбрать на будущее.
На диаграмме представлен сценарий А/В-тестирования, в которой разные версии
веб-приложения тестируются одновременно для оценки их производительности,
вовлеченности пользователя или других заранее определенных метрик. В этой
архитектуре процесс А/В-тестирования выглядит следующим образом.
1. Распределение трафика: балансировщик нагрузки приложения играет
важную роль в этой схеме: он направляет входящий трафик разным верси-
ям веб-приложения. В рассматриваемом сценарии большая часть трафика
(90 %) направляется стабильной рабочей версии (V1.1), тогда как новые
тестируемые версии, V1.2 и V1.3, получают меньшие доли трафика (7 и 3 %
соответственно).
2. Парк веб-серверов: каждая версия приложения работает на отдельной груп-
пе веб-серверов или экземпляров. Это гарантирует, что изменения в одной
версии не затронут другие версии. Такая изоляция важна для получения
точных результатов тестирования. Версия, получающая большую часть
трафика, служит контрольной группой, а остальные версии с изменениями
или новой функциональностью — тестовыми группами.
k2b Глава 11. DevOps и фреймворк архитектуры решений
3. База данных: все версии приложения взаимодействуют с одной базой данных
на бэкенде. Это стандартная практика для A/В-тестов, где разные варианты
пользовательского интерфейса используют общие данные. Однако при этом
необходимо проверить совместимость схем базы данных между версиями
и единообразие операций с данными, чтобы предотвратить ошибки или не-
согласованность при работе с данными.
В процессе А/В-тестирования необходимо непрерывно отслеживать метрики
производительности, чтобы оценить, как каждая версия приложения работает
в реальных условиях. К числу таких метрик относятся время отклика, частота
ошибок, степень использования ресурсов и т. д. После сбора значительного
объема данных результаты анализируются и делается вывод, какая версия
приложения лучше всего соответствует критериям тестирования. На осно-
вании результатов А/В-тестов принимается решение о том, стоит ли полностью
развернуть новую версию, продолжать вносить изменения или отменить их.
Рис. 11.10. Проверка новой функциональности
с помощью А/В-тестирования
Инструменты DevOps для CI/CD 427
Инструменты DevOps для CI/CD
Для создания пайплайна CI/CD разработчику потребуются инструменты. К их
числу относится редактор кода, репозиторий исходного кода, сервер сборки,
система развертывания и средства оркестрации всего пайплайна CI. Рассмотрим
некоторые популярные средства разработчика для DevOps — как для облачных,
так и для локальных сред.
Редактор кода
В практике DevOps для автоматизации среды часто приходится писать скрипты.
Для этого можно воспользоваться редактором Асе или облачной интегрирован-
ной средой разработки (IDE) AWS Cloud9. В Асе есть подсветка синтаксиса
и другая удобная для разработчиков функциональность. Cloud9 интегрируется
с платформой AWS, что позволяет разработчикам легко создавать бессервер-
ные приложения и работать с сервисами AWS. Также Cloud9 поддерживает
совместное программирование и основные средства для работы с популярными
языками программирования.
Можно использовать редактор кода на локальном компьютере или же установить
его на локальном сервере, подключенном к средам приложения (разработки,
тестирования, продакшен) для взаимодействия с ними. В среде сохраняются
файлы проекта и запускаются средства для разработки приложений. Можно
сохранять файлы локально на экземпляре или сервере или же клонировать
удаленный репозиторий кода в свою среду. AWS Cloud9 IDE — это облачная
IDE, которая предоставляется как управляемый сервис.
Асе позволяет быстро и легко писать код. Это редактор кода на базе веб-
технологий, но по производительности он не уступает таким популярным
десктопным редакторам кода, как Eclipse, Vim, Visual Studio Code (VS Code)
и т. д. Он поддерживает различные стандартные средства IDE, например дина-
мическую подсветку синтаксиса и выделение парных скобок, автоматическую
расстановка отступов и автозавершение, переключение между вкладками,
интеграцию с системами контроля версий и множественное выделение. Асе
работает с большими файлами, содержащими сотни тысяч строк, без задерж-
ки при вводе. Он обладает встроенной поддержкой всех популярных языков
программирования и средств отладки; кроме того, он позволяет устанавливать
свои инструменты. Среди десктопных IDE для инженеров DevOps также по-
пулярны VS Code и Eclipse.
Управление исходным кодом
Существует несколько вариантов для выбора репозитория исходного кода.
Можно создать собственный сервер Git и управлять им. Можно также вос-
пользоваться сервисом хостинга — таким, как GitHub или Bitbucket. Если вы
ищете облачное решение, AWS CodeCommit предлагает безопасную, хорошо
428 Глава 11. DevOps и фреймворк архитектуры решений
масштабируемую систему управления исходным кодом для размещения при-
ватных репозиториев Git.
Для репозитория кода необходимо настроить аутентификацию и авторизацию,
чтобы организовать доступ для чтения/записи кода со стороны участников
команд. Можно применить шифрование данных при передаче и при хранении.
При передаче кода в репозиторий (git push) данные шифруются и сохраняются.
При извлечении кода из репозитория (git pull) данные дешифруются, а затем
отправляются вызывающей стороне. Пользователь должен пройти аутенти-
фикацию с соответствующим уровнем доступа к репозиторию. Чтобы данные
шифровались, можно передавать их по шифрованным сетевым подключениям
с использованием протоколов HTTPS или SSH.
Сервер CI
Сервер CI называется сервером сборки. Когда команды одновременно рабо-
тают над разными ветками, задача их слияния в основную ветку усложняется.
CI в этом сценарии играет ключевую роль. Хуки сервера CI предоставляют
возможность инициировать сборку по наступлению события при сохранении
кода в репозитории. Хуки, встроенные практически в каждую систему кон-
троля версий, ссылаются на специальные скрипты, запускаемые по заданным
действиям в репозитории. Хуки могут выполняться на стороне клиента или на
стороне сервера.
Разработчики обычно используют пул-реквесты для уведомлений и взаимного
код-ревью до слияния кода в главную ветку. Сервер CI предоставляет веб-
интерфейс для просмотра изменений перед их включением в итоговый проект.
Если с предлагаемыми изменениями возникнут проблемы, исходный код может
быть возвращен разработчику для переделки в соответствии с требованиями
организации.
Как показано на рис. 11.11, хуки на стороне сервера в сочетании с сервером CI
используются для повышения скорости интеграции.
Остановка развертывания в случае ошибки при сборке и отправка отчета о сборке команде разработки
Рис. 11.11. Автоматизация CI
Инструменты DevOps для CI/CD 429
Как показано на диаграмме, при помощи хука post-receive можно указать
новым веткам запустить тесты на сервере CI, чтобы убедиться, что новая
сборка правильно интегрируется и все компоненты функционируют как надо.
Разработчик получает уведомления о провалах тестов и знает, что слияние
его ветки с главной веткой должно происходить только после исправления
всех проблем. Разработчик может провести сборку из своей ветки, протести-
ровать изменения в ней и получить обратную связь о том, насколько хорошо
работают его изменения, прежде чем решить, стоит ли проводить слияние
с главной веткой.
Запуск интеграционных и модульных тестов значительно сокращает риски при
слиянии ветки с главной. Хуки также можно настроить для тестирования слия-
ний с главной ветвью и блокирования любых изменений, которые не проходят
тесты. Интеграция лучше всего достигается при наличии сервера CI.
Jenkins — самый популярный
инструмент для создания сер-
вера CI. Как показано на рис.
11.12, кластер Jenkins можно
разместить в парке серверов
AWS ЕС2 (Elastic Compute
Cloud) и автоматически мас-
штабировать его в соответствии
с нагрузкой.
В случае перегрузки контроллер
Jenkins поручает сборку экзем-
пляру агентского узла. Когда
нагрузка снижается, контроллер
автоматически завершает экзем-
пляры агентов.
Агент Jenkins Агент Jenkins Агент Jenkins
Рис. 11.12. Автомасштабирование
Cl-серверов Jenkins
Тем не менее поддерживать безопасность и устанавливать патчи на сервере при-
дется самостоятельно. Для платформенных облачных решений и управляемых
сервисов можно воспользоваться управляемыми сервисами сборки кода (таки-
ми, как AWS CodeBuild); это избавит от необходимости в администрировании
сервера и значительно сократит затраты с моделью оплаты по фактическому
использованию — сервис масштабируется по мере необходимости. Команда
получает возможность сосредоточиться на отправке кода, а сервис сам создает
все артефакты.
Сервер CI помогает собирать корректную версию кода из репозитория исходно-
го кода, обеспечивая совместную работу членов команды разработчиков, тогда
как развертывание кода позволяет команде подготовить код к тестированию
и релизу для конечных пользователей. В следующем разделе развертывание
кода рассматривается более подробно.
430 Глава 11. DevOps и фреймворк архитектуры решений
Развертывание кода
По завершении сборки можно развернуть сервер Jenkins или выбрать AWS
CodeDeploy в качестве облачно-ориентированного управляемого сервиса. Для
создания скрипта развертывания можно воспользоваться популярными инстру-
ментами (например, Chef или Puppet). Поддерживаются следующие варианты
конфигурации развертывания.
• OneAtATime: в любой момент времени только один экземпляр в группе раз-
вертывания создает новое развертывание. Представим, что развертывание
для заданного экземпляра завершилось неудачей. В таком случае скрипт
остановит его и вернет сообщение об ошибке с указанием количества успеш-
ных и ошибочных установок.
• Half AtATime: новое развертывание создается половиной экземпляров в группе
развертывания. Развертывание проходит успешно, если половина экземпля-
ров успешно устанавливает изменение. Вариант Half AtATime хорошо подходит
для рабочих/тестовых сред, в которых половина экземпляров обновляется
новой версией, а другая половина остается в рабочем состоянии и доступна
со старой версией.
• AllAtOnce: каждый экземпляр устанавливает последнюю доступную версию,
когда в следующий раз опрашивает сервис развертывания. Этот вариант
лучше использовать для развертываний в средах разработки и тестирования,
так как он может привести к установке нефункциональной версии на каждом
экземпляре в группе развертывания.
• Custom: эта команда может использоваться для создания нестандартной кон-
фигурации развертывания с указанием фиксированного количества работо-
способных хостов, которые должны существовать в группе развертывания
в любой конкретный момент. Этот вариант представляет собой более гибкую
реализацию варианта OneAtATime. Он допускает возможность того, что раз-
вертывание завершится неудачей на одном или двух экземплярах, которые
были повреждены или неправильно сконфигурированы.
На рис. 11.13 представлены события жизненного цикла развертывания.
Агент развертывания проходит через серию этапов, они называются событиями
жизненного цикла. Рассмотрим их более подробно.
1. Ар plication Stop: чтобы запустить развертывание, первым шагом должна
стать остановка сервера приложения, прерывающая обработку трафика на
время копирования файлов. Примеры серверов приложений — Tomcat, JBoss
и WebSphere.
2. DownloadBundle: после остановки сервера приложения агент развертывания
начинает загружать заранее созданный пакет развертывания из хранилища
артефактов — такого, как JFrog Artifactory. Там хранится двоичный файл
приложения, который можно развернуть и протестировать до запуска новой
версии.
Инструменты DevOps для CI/CD 431
3. Beforelnstall: агент развертывания инициирует различные действия, пред-
шествующие установке, — например, создание резервной копии текущей
версии и необходимое обновление конфигурации с помощью скрипта.
4. Install: на этом шаге агенты развертывания начинают установку — например,
запускают скрипт Maven или Ant для установки приложения Java.
5. Afterlnstall: агент развертывания инициирует этот шаг после завершения
установки приложения. Он может включать обновление конфигурации
после установки (например, настроек локальной памяти и параметров
журнала).
6. Applicationstart: на этом шаге агент запускает приложение и оповещает
группу эксплуатации об успехе или неудаче.
7. ValidateService: последний этап — проверка (валидация). В него входит
автоматизированная проверка работоспособности и интеграционные тесты
для проверки, правильно ли установлена новая версия приложения. Агент
также отправляет уведомление в случае успешного тестирования.
Рис. 11.13. События жизненного цикла развертывания
Мы рассмотрели разные стратегии и этапы развертывания кода как независимые
компоненты. Однако для создания автоматизированного пайплайна CI/CD все
фазы DevOps необходимо объединить. Более подробное знакомство с пайплай-
ном кода поможет создавать сквозные пайплайны CI/CD.
432 Глава 11. DevOps и фреймворк архитектуры решений
Пайплайн кода
Пайплайн кода объединяет все компоненты для реализации CD. Весь процесс
выпуска полностью автоматизируется в CD, включая сборку и развертывание ра-
бочей версии. С течением времени, поэкспериментировав, вы сможете настроить
надежный пайплайн CI/CD. Путь к запуску рабочей версии автоматизирован,
что обеспечивает быстрое развертывание функциональности и немедленную об-
ратную связь от пользователей. Для координации всего пайплайна кода можно
воспользоваться облачно-ориентированными управляемыми сервисами (такими,
как AWS CodePipeline) или сервером Jenkins.
Пайплайн кода позволяет добавлять новые действия на разные стадии пай-
плайна CI/CD. Каждое действие может быть связано с поставщиком, который
это действие выполняет. Вот основные категории действий в пайплайне кода
и примеры поставщиков.
• Исходный код: код приложения должен храниться в центральном репозито-
рии с контролем версий — репозитории исходного кода. Примеры популярных
репозиториев кода: AWS CodeCommit, Bitbucket, GitHub, CVS (Concurrent
Versions System), Subversion (SVN) и др.
• Сборка: система сборки извлекает код из репозитория исходного кода и соз-
дает двоичный пакет приложения. Примеры популярных систем сборки: AWS
CodeBuild, Jenkins, Solano CI и др. После того как сборка будет завершена,
двоичные файлы можно сохранить в хранилище артефактов — например,
JFrog.
• Развертывание: инструменты развертывания упрощают задачу развертыва-
ния двоичных файлов приложения на сервере. Примеры популярных инстру-
ментов: AWS Elastic Beanstalk, AWS CodeDeploy, Chef, Puppet, Jenkins и др.
• Тестирование: автоматизированные инструменты тестирования помогают
завершить и выполнить проверку после развертывания. Примеры популяр-
ных инструментов тестирования: Jenkins, BlazeMeter, Ghost Inspector и т. д.
• Вспомогательные операции: для выполнения таких операций, например
резервного копирования или уведомлений, можно воспользоваться скрип-
том на основе событий. Для выполнения специальных операций может
использоваться любой скриптовый язык: командной оболочки, PowerShell
или Python.
• Подтверждение: исключительно важный этап CD. Можно запросить ручное
подтверждение через автоматизированную отправку сообщения электронной
почты либо автоматизировать процесс подтверждения на уровне инстру-
ментов.
В этом разделе вы узнали о различных инструментах DevOps для управления
жизненным циклом разработки продукта (SDLC, sotware development life
cycle) — редакторе кода, репозитории, инструментах сборки, тестирования и раз-
вертывания. Другие инструменты, которые часто интегрируются в пайплайны
Реализация лучших практик DevOps 433
DevOps, — непрерывное ведение журнала, непрерывный мониторинг и эксплуа-
тация, о которых вы узнали в главе 9 «Операционное совершенство». Мы также
рассмотрели методы DevOps, применимые на каждом этапе SDLC. В следующем
разделе речь пойдет о лучших практиках и антипаттернах.
Реализация лучших практик DevOps
Допустим, что при построении пайплайна CI/CD необходимо создать проект
и добавить в него участников. Дашборд проекта наглядно представляет прохо-
ждение кода по пайплайну развертывания, ведет мониторинг сборки, инициирует
уведомления и отслеживает активности приложения. На рис. 11.14 представлен
хорошо определенный пайплайн DevOps.
Рис. 11.14. Образцовый поток операций CI/CD
При проектировании пайплайна необходимо учитывать следующее.
• Количество стадий: основные стадии — развертывание, интеграция, систем-
ная стадия, одобрение пользователем и продакшен. В некоторых организациях
также включаются стадии разработки, альфа, бета и релиза.
• Типы тестов на каждой стадии: на каждой стадии могут выполняться тесты
разных типов: модульные, интеграционные, системные, UAT, тесты на общую
работоспособность, нагрузочные тесты и тесты A/В на продакшен.
• Последовательность выполнения тестов: тесты могут выполняться парал-
лельно или последовательно.
• Мониторинг и отчетность: отслеживайте дефекты и сбои в системе и от-
правляйте уведомление о возникающих проблемах.
434
Глава 11. DevOps и фреймворк архитектуры решений
• Предоставление инфраструктуры: методы предоставления инфраструктуры
для каждой стадии.
• Откат: определите стратегию отката для возврата к предыдущей версии
в случае необходимости.
Если ручное вмешательство происходит там, где его можно избежать, это
замедляет процесс разработки. Таким образом, автоматизация процесса с ис-
пользованием CD ускорит его.
Еще один распространенный антипаттерн — хранение данных конфигурации
сборки внутри кода, а также ситуация, когда разработчики используют разные
инструменты сборки, что приводит к рассогласованию сборок. Чтобы понять,
почему конкретная сборка работает в одной среде, но не работает в других, по-
требуется много времени и усилий. Для решения этой проблемы лучше хранить
конфигурации сборки за пределами кода.
Предоставление доступа к этим конфигурациям для инструментов, обеспечи-
вающих согласованность сборок, повышает качество автоматизации и значи-
тельно ускоряет масштабирование процесса. Отказ от использования процесса
CD может привести к ночным авральным попыткам заставить сборку работать.
Проектируйте CD для быстрого провала (fail fast); это сократит риск неприятных
сюрпризов, возникающих в последний момент.
Внешнее хранение конфигураций, относящихся к конкретным средам, способ-
ствует поддержанию согласованности и масштабируемости между сборками.
Перечислим некоторые инструменты и сервисы, упрощающие эту абстракцию.
• Хранилище параметров AWS Systems Manager Parameter Store: предо-
ставляет безопасное иерархическое хранилище для управления данными
конфигурации и секретами. Здесь можно хранить такие данные, как па-
роли, строки подключения к базам данных и коды лицензий как значения
параметров.
• ConfigMaps и Secrets в Kubernetes: объекты Kubernetes, позволяющие от-
делить артефакты конфигурации от содержимого образов, чтобы контейне-
ризованные приложения оставались портируемыми.
• Docker Swarm Secrets: используется для управления конфиденциальными
данными в контейнерах Docker; предоставляет возможность безопасной
передачи и хранения секретов в кластере Swarm.
• HashiCorp Consul: сетевое решение для автоматизации сетевых конфигура-
ций с использованием распределенных хранилищ пар «ключ — значение».
При помощи этих инструментов можно управлять конфигурациями и секретами
за пределами кода приложения и шаблонов, что упрощает управление и ротацию
без повторного развертывания или изменения приложения.
Мониторинг ключевых показателей эффективности (KPI, Key Performance
Indicators) играет важнейшую роль для эффективной оценки влияния CI/CD
в структуре DevOps. Важнейшие KPI в области CI/CD:
Создание процессов DevOps и DevSecOps на облачных платформах 435
• частота развертывания — сигнализирует о том, насколько часто обновления
достигают продакшен, и отражает гибкость процесса выпуска;
• общее время внесения изменений, то есть продолжительность периода от
коммита до живого развертывания; чем короче интервалы, тем эффективнее
цикл разработки;
• частота сбоев при изменениях — определяет долю развертываний, приво-
дящих к сбоям; чем она ниже, тем выше стабильность развертывания;
• среднее время восстановления (MTTR, mean time to recovery) оценивает сред-
нюю продолжительность восстановления при сбоях; более быстрое восстанов-
ление свидетельствует об эффективности управления инцидентами в команде;
• частота прохождения автоматизированных тестов оценивает надежность кода
через частоту успешности автоматизированных тестов в каждом цикле CI/CD.
Для применения лучших практик на каждом шаге разработки приложения
можно использовать принципы методологии Twelve-Factor Арр (12-факторное
приложение, https://12factor.net/), принятой для сквозной разработки и поставки
веб-приложений. Методология применима на любых платформах программи-
рования независимо от языка программирования.
В наши дни многие продукты имеют формат веб-приложений и используют
облачные платформы. Посмотрим, как создать сквозной процесс DevOps
и автоматизировать безопасность в облаке.
Создание процессов DevOps и DevSecOps
на облачных платформах
Как вы узнали из предыдущих разделов, построение CI/CD-пайплайна требует
множества инструментов, а добавление автоматизации безопасности только
повышает сложность. Интеграция различных инструментов и консолидация
результатов оценки уязвимости «с нуля» может быть сложной задачей. Облачные
провайдеры (например, AWS) предлагают необходимую гибкость для создания
DevSecOps-пайплайнов. Это включает простую интеграцию как облачно-ориен-
тированных, так и сторонних инструментов, а также возможность эффективного
агрегирования результатов анализа безопасности.
Архитектура DevSecOps-пайплайна использует практики CI/CD, включая
инструменты SCA, SAST и DAST.
• Инструменты SCA (композитный анализ программного продукта) анализи-
руют компоненты с открытым исходным кодом для выявления известных
уязвимостей, проблем лицензирования и устаревших библиотек. Они могут
автоматизировать процесс проверки обновлений и патчей безопасности,
упрощая управление зависимостями приложения.
• Инструменты SAST (статическое тестирование безопасности приложения)
предназначены для анализа исходного кода или скомпилированных версий
436
Глава 11. DevOps и фреймворк архитектуры решений
кода, чтобы выявлять уязвимости безопасности. Они могут обнаруживать
такие проблемы, как ошибки проверки ввода, небезопасные зависимости
и потенциальные бэкдоры без выполнения кода.
• Инструменты DAST (динамическое тестирование безопасности приложения)
оценивают работающее приложение на предмет уязвимостей. В отличие от
инструментов SAST, анализирующих статический код, инструменты DAST
взаимодействуют с приложением снаружи, выполняя тестирование по прин-
ципу «черного ящика» для выявления таких проблем, как SQL-инъекции,
межсайтовый скриптинг и проблемы с аутентификацией.
Интеграция этих инструментов в пайплайн CI/CD позволяет организовать не-
прерывное и автоматизированное тестирование безопасности. Таким образом
команды быстрее могут обнаруживать и решать проблемы безопасности, что по-
вышает общую безопасность приложения. На рис. 11.15 наглядно представлены
концепции автоматизации безопасности в пайплайне.
Анализ
сканирования |
Lambda
Security Hub
AWS Config
IAST
DAST
CppkfKFX -VttUC OE
Стейдж
Развер-
тыва-
AWS Code Amazon S3
Artifacts
CodePipeline
CodeDeploy
Elastic Container Service
Команда
разработки
CodeCommit CodeBuild CodeDeploy CodeBuild
----------------1 Ручное I----------------
| подтверждение j
AWS
CloudTrailArtifacts
Развертывание
Тестирование
Развертывание (DAST, IAST) Развертывание
Elastic Container Service
Продакшен Б ।
Команда DevOps/ Simple Notification
разработки Service
□
□□□
Событие CloudWatch
Журналы
CloudWatch
Роль AWS 1AM
Хранилище
параметров
Рис. 11.15. Архитектура пайплайна CI/CD процесса DevSecOps
на облачной платформе AWS
Создание процессов DevOps и DevSecOps на облачных платформах 437
Как показано на диаграмме, пайплайн CI/CD срабатывает при отправке коммита
на Git Hub. Событие для запуска AWS CodePipeline генерируется при помощи
AWS CloudWatch. AWS CodePipeline координирует работу пайплайна CI/CD,
включая сохранение кода, сборку и развертывание. AWS CodeBuild компили-
рует сборку, после чего отправляет полученные артефакты в хранилище AWS
CodeArtifact. Для запуска процесса сканирования AWS CodeBuild получает под-
робности аутентификации, включая маркеры для инструментов сканирования,
из AWS Parameter Store.
После успешного завершения развертывания CodeBuild запускает процесс DAST.
Если этот процесс обнаружит уязвимости, CodeBuild запускает функцию Lambda.
Функция регистрирует информацию о проблеме безопасности в AWS Security
Hub. Представим, что DAST не находит проблем с безопасностью. В таком случае
сборка переходит к утверждению, а пайплайн уведомляет ответственного за под-
тверждение о необходимости выполнить действие для передачи сборки в рабочую
среду AWS ECS. Во время выполнения CI/CD-пайплайна AWS CloudWatch
отслеживает все изменения и отправляет уведомления по электронной почте
команде разработки и DevOps через систему уведомлений SNS.
AWS CloudTrail отслеживает все критические изменения (такие, как обновление,
удаление и создание пайплайна) и отправляет уведомления команде DevOps для
целей аудита. Кроме того, AWS Config отслеживает все изменения конфигурации.
В DevSecOps защита пайплайна CI/CD достигается при помощи ролей AWS
Identity и Access Management (IAM), которые ограничивают доступ необходи-
мыми ресурсами. Для защиты данных пайплайна как при хранении, так и при
передаче используется шифрование и SSL. Конфиденциальные данные — такие,
как маркеры API и пароли — безопасно хранятся в AWS Parameter Store.
Централизованное хранение результатов анализа безопасности в AWS Security
Hub упрощает автоматизацию процессов восстановления. В зависимости от
природы проблемы безопасности для выполнения необходимых действий может
быть запущена функция Lambda. Например, при случайном открытии доступа
к порту SSH система может автоматически ограничить доступ к серверу из ин-
тернета. Эта автоматизация снимает нагрузку с DevOps и команд безопасности,
позволяя им решать проблемы уязвимостей с помощью одного инструмента
вместо управления несколькими дашбордами.
Решение проблем с угрозами безопасности на ранней стадии жизненного цикла
приложения может значительно сократить затраты на внесение изменений.
Автоматизация этого процесса ускоряет доставку изменений, поэтому пай-
плайн DevSecOps становится неотъемлемым условием успешной разработки
приложения.
DevOps объединяет культуру, практики и инструменты для интеграции про-
цессов разработки и эксплуатации приложений, что ускоряет внедрение новой
функциональности. DevSecOps расширяет эту концепцию, включая в процесс
DevOps безопасность. Это гарантирует быструю доставку безопасных изменений,
438 Глава 11. DevOps и фреймворк архитектуры решений
отвечающих требованиям комплаенса, а также согласованную автоматизиро-
ванную эксплуатацию. Подобная интеграция исключительно важна для под-
держания безопасной, эффективной и гибкой среды разработки приложения.
Итоги
В этой главе вы узнали об основных составляющих эффективной практики
DevOps, а также о ее преимуществах, CI/CD, непрерывном мониторинге
и непрерывном улучшении. Гибкость CI/CD может быть достигнута только
повсеместным применением автоматизации. Вы узнали об 1аС и управлении
конфигурацией в контексте автоматизации. Также были рассмотрены ин-
струменты автоматизации (например, Chef, Puppet и Ansible) для управления
конфигурацией.
Так как приоритетом разработки является безопасность, мы рассмотрели прак-
тику DevSecOps. По сути она представляет собой DevOps с учетом безопасности.
Непрерывное развертывание (CD) является одним из важнейших условий
DevOps. Мы поговорили о существующих стратегиях развертывания: сколь-
зящем, сине-зеленом и красно-черном. Еще одним условием обеспечения ка-
чества продукта является тестирование. Вы узнали о концепции непрерывного
тестирования в DevOps и о том, как А/В-тестирование поможет улучшить
продукт за счет получения прямой обратной связи от клиентов.
Мы обсудили стадии CI/CD-пайплайна, инструменты и сервисы, которые
используются на каждой стадии, и лучшие практики создания надежного С1/
CD-пайплайна. Мы также разобрали, как работают отдельные сервисы, и об-
судили возможности интеграции сервисов для построения сложного решения.
Итак, вы изучили параметры архитектуры решений. Поскольку каждая органи-
зация работает с большими объемами данных, она тратит много усилий на их
анализ. В следующей главе вы узнаете о сборе, обработке и потреблении данных
для их более глубокого понимания.
ГЛАВА 12
ИНЖЕНЕРИЯ ДАННЫХ
ДЛЯ АРХИТЕКТУР РЕШЕНИЙ
В предыдущей главе вы узнали о процессе DevOps, который автоматизирует
пайплайн развертывания приложений и продвигает культуру совместной ра-
боты среди команд разработки, эксплуатации и безопасности. В этой главе вы
познакомитесь с инженерией данных, в том числе с инструментами и метода-
ми, используемыми для сбора данных из различных частей приложения для
получения аналитической информации, которая может направлять развитие
бизнеса.
В интернете и в цифровую эпоху повсюду стремительно генерируются огромные
объемы данных. Быстро извлекать из них аналитическую информацию — не-
простая задача. Чтобы получать полезные для бизнеса результаты, необходимо
постоянно заниматься поглощением, сохранением и обработкой этих данных.
Слияние облачных, мобильных и социальных технологий способствует непре-
рывным достижениям во многих областях — таких, как геномика и естественные
науки. Глубокий анализ данных для их лучшего понимания имеет огромную
ценность. Современные стриминговые системы должны непрерывно генери-
ровать результаты обработки данных, поступающих с высокой частотой, при
низкой задержке.
Концепция больших данных (Big Data) не сводится к их простому сбору и ана-
лизу. Действительная ценность, которую организации могут извлечь из своих
данных, может использоваться для получения аналитической информации
и создания конкурентных преимуществ. Не все решения для больших данных
подразумевают визуализацию. Многие — например, машинное обучение (МО)
и другая прогнозная аналитика — поставляют свои выводы программно другим
инструментам или приложениям, извлекая информацию и отвечая заданным
образом.
Как это часто бывает, высокая скорость получения результатов обходится доро-
го, и Big Data не исключение. Иногда ответы не нужны немедленно, а задержка
и пропускная способность решения достаточно гибкие, так что на завершение
440 Глава 12. Инженерия данных для архитектур решений
обработки могут понадобиться часы. В других ситуациях (например, в рамках
прогнозной аналитики) ответы нужны сразу же после получения данных.
В этой главе рассматриваются следующие темы, относящиеся к обработке
и управлению потребностями в области больших данных.
• Что представляет собой архитектура Big Data?
• Проектирование пайплайнов обработки Big Data.
• Поглощение данных, хранение, обработка и аналитика.
• Визуализация данных.
• Проектирование архитектур Big Data.
• Лучшие практики архитектуры Big Data.
К концу этой главы вы узнаете, как проектировать архитектуру больших данных
и аналитики. Вы изучите основные этапы пайплайна больших данных, вклю-
чая поглощение данных, хранение, обработку, визуализацию и архитектурные
паттерны.
Что представляет собой архитектура Big Data?
Огромный объем собранных данных может создавать проблемы. С накоплением
все большего объема данных управлять и перемещать их вместе с нижележащей
инфраструктурой становится все сложнее. Рост популярности облака упростил
возможность перемещения приложений на облачные платформы.
Поступление данных из разных источников приводит к росту объемов, скорости
и разнообразия данных. Ниже приведены лишь несколько примеров распро-
страненных источников данных, генерируемых компьютером.
• Журналы серверов приложений: журналы приложений и игр.
• Журналы сведений о посещениях: активность на сайтах и история про-
смотров.
• Данные от датчиков: погоды, воды, энергии ветра, интеллектуальных сетей.
• Графика и видео: камеры уличного движения и безопасности.
Компьютеры могут генерировать разные виды данных, от полуструктурирован-
ных журналов до неструктурированных двоичных данных. Сгенерированные
данные могут использоваться для поиска по шаблону или нахождения корре-
ляций в данных, на основе чего генерируются рекомендации для социальных
сетей и сетевых игр. Данные, сгенерированные компьютером, — блоги, отзывы,
электронная почта, графика, восприятие бренда — также могут использоваться
для отслеживания поведения приложений или сервисов.
К данным, генерируемым человеком, относятся, например, результаты поиска
по электронной почте, запросы на естественном языке, анализ тональности
и рекомендации продуктов. Анализ социальных графов может создавать реко-
мендации продуктов на основании вашего круга друзей, профессий, которые
Что представляет собой архитектура Big Data? 441
вы считаете интересными, или даже напоминания о днях рождения, юбилеях
и т. д. в вашем кругу друзей.
Назовем типичные препятствия, которые мешают командам по аналитике данных
приносить максимальную пользу своим организациям.
• Ограниченная информация о пользовательском опыте и эксплуатации:
чтобы создавать новые варианты взаимодействия с пользователями, орга-
низации должны лучше понимать свой бизнес. Сложный и затратный сбор
данных, системы обработки и дополнительные расходы на масштабирование
заставляют организации ограничивать типы и объем собираемых и анали-
зируемых данных.
• Необходимость ускоренного принятия решений. Это комплексная проблема,
включающая две составляющие:
традиционные системы данных перегружены, из-за чего завершение ра-
бочих нагрузок требует больше времени;
на принятие многих решений должны уходить только секунды или
минуты, из-за чего системы должны собирать и обрабатывать данные
в реальном времени.
• Возможность инноваций на базе МО: организации добавляют и расширяют
команды data science для оптимизации и развития бизнеса. Командам тре-
буется расширенный доступ к данным из выбранных ими инструментов без
типичных преград и процессов, которые замедляют их работу.
• Технический персонал и затраты на масштабирование самоуправляемых
инфраструктур: клиентам, которые управляют инфраструктурой локально,
необходима помощь с быстрым масштабированием под потребности бизнеса.
Управление инфраструктурой, высокая доступность, масштабирование и мо-
ниторинг операций — все это занимает время, особенно в масштабе.
В архитектуре Big Data общий поток операций крупного пайплайна данных на-
чинается с данных и завершается результатами. Путь от начала к концу зависит
от многих факторов. На рис. 12.1 изображен пайплайн потока данных, который
помогает спроектировать архитектуру данных.
Как видно из диаграммы, стандартный рабочий процесс пайплайна Big Data
включает следующие этапы.
1. Сбор (поглощение) данных соответствующим инструментом.
2. Долгосрочное хранение данных.
3. Обработка или анализ данных. Инструмент берет данные из хранилища, вы-
полняет операции, а затем снова сохраняет обработанные данные.
4. Данные используются другими инструментами обработки/анализа или тем
же инструментом для получения дополнительной информации.
5. Чтобы результаты были полезными для бизнес-пользователей, создается
их визуализация с использованием инструментов бизнес-аналитики (BI)
либо они передаются алгоритму МО для прогнозирования. Представленные
442 Глава 12. Инженерия данных для архитектур решений
ответы дают пользователю более глубокое понимание данных для принятия
последующих бизнес-решений.
Задержка
Затраты
Рис. 12.1. Пайплайн Big Data для проектирования архитектуры данных
Инструменты, развертываемые в пайплайне, определяют время ответа, которое
представляет собой задержку между созданием данных и получением резуль-
татов. Лучший способ проектирования решений данных с учетом задержки —
обеспечить баланс пропускной способности и затрат, поскольку повышение
производительности и сокращение задержки обычно приводит к повышению
затрат. Например, финансовая платформа требует аналитики в реальном вре-
мени, чтобы немедленно предоставить пользователям результаты для быстрого
принятия решений.
Для этого платформа может воспользоваться дорогостоящим пайплайном
обработки данных, который включает базы данных в памяти, потоковую об-
работку в реальном времени и скоростные сервисы поглощения данных. Эта
конфигурация обеспечивает низкую задержку, позволяя брокерам мгновен-
но реагировать на изменения рынка. В данном случае бизнес-потребность
в аналитике реального времени оправдывает высокие затраты на архитектуру
с низкой задержкой.
Проектирование пайплайнов
обработки Big Data
Одна из самых серьезных ошибок, которые встречаются во многих архитектурах
Big Data, — обработка нескольких стадий пайплайна данных одним инструмен-
том. Парк серверов, управляющих сквозным пайплайном данных, от их хранения
и преобразования до визуализации, может быть самым простым решением, но
он также наиболее уязвим для взлома. Такие сильносвязанные архитектуры
Проектирование пайплайнов обработки Big Data 443
Big Data обычно не обеспечивают оптимального баланса пропускной способ-
ности и затрат. При проектировании архитектуры данных следует использовать
принципы FLAIR:
• F — поисковая доступность (Findability): возможность простого обнаруже-
ния доступных данных и обращения к их метаданным, включающим такую
информацию, как владелец и классификация данных, наряду с другими кри-
тически важными атрибутами, необходимыми для рационального управления
данными и комплаенса;
• L — происхождение (Lineage): возможность отслеживания источника дан-
ных, их перемещений и истории, а также понимания и визуализации потоков
данных от источников к точкам потребления;
• А — доступность (Accessibility): возможность запрашивать и получать
сертификаты безопасности, открывающие доступ к конкретному массиву
данных. Также подразумевает необходимость в сетевой инфраструктуре,
поддерживающей эффективный доступ к данным;
• I — совместимость (Interoperability): хранение данных в форматах, к которым
могут обращаться и которые могут использовать большинство (если не все)
внутренних систем обработки;
• R — повторное использование (Reusability): данные должны быть документи-
рованы с заданной схемой, а источник данных должен быть четко обозначен.
Этот принцип часто включает принципы управления основными данными
(MDM, Master Data Management), ориентированного на управление крити-
чески важными данными из разных предметных областей; таким образом
формируется единая отправная точка для работы с данными.
Архитекторы больших данных рекомендуют разделять в пайплайне фазы по-
глощения, хранения, обработки и получения аналитики. Разделение хранения
и обработки на несколько стадий обладает рядом преимуществ, включая повы-
шение отказоустойчивости. Например, если что-то пойдет не так на втором круге
обработки и оборудование, выделенное для этой задачи, выйдет из строя, вам
не придется возвращаться к началу пайплайна; система сможет продолжить со
второй стадии хранения. Отделение хранения от уровней обработки позволяет
выполнять операции чтения и записи из нескольких хранилищ данных.
На рис. 12.2 изображены различные инструменты и процессы пайплайна архи-
тектуры Big Data.
Факторы, которые необходимо учитывать при выборе инструментов для архи-
тектур больших данных:
• структура данных;
• максимальная допустимая задержка;
• минимальная допустимая пропускная способность;
• типичные шаблоны обращений конечных пользователей системы.
4U
Глава 12. Инженерия данных для архитектур решений
Обработка
и анализ
Визуализация
Near Real-Time
Экосистема Hadoop
Хранилище данных
Машинное обучение
Аналитика Elasticsearch
Встраиваемые
дашборды
Обработка и перемещение
данных
Аналитика для
приложений Java
Ситуативная аналитика
Бизнес-аналитика
и визуализация данных
I
I-------------------------------f
I Elasticsearch Analytics
Рис. 12.2. Инструменты и процессы архитектуры Big Data
Структура данных влияет как на инструменты, используемые для их обработки,
так и на место их хранения. Упорядочение данных и размер каждого объекта,
который вы сохраняете и читаете, также играют важную роль при принятии
решения. Соотношение задержки / пропускной способности и затрат опреде-
ляет время ответа.
Шаблоны пользовательских обращений — еще один важный компонент. Одни
задания требуют регулярного соединения многих связанных таблиц, другие —
ежедневного или менее частого сохранения данных. Третьи задания требуют
сравнения данных из широкого диапазона источников, четвертые извлекают
данные из одной неструктурированной таблицы. Если вы знаете, как конечные
пользователи будут чаще всего работать с данными, это поможет вам определить
ширину и глубину архитектуры Big Data. В следующем разделе все процессы
и инструменты, задействованные в архитектуре больших данных, рассматри-
ваются более подробно.
Поглощение данных, сохранение, обработка
и аналитика
Чтобы преобразовать необработанные данные в информацию, которая может
стать основанием для принятия решений и стратегического планирования, их
Поглощение данных, сохранение, обработка и аналитика 445
необходимо провести через несколько этапов. Все начинается с поглощения
данных (data ingestion) — сбора данных из разных источников. Это могут быть
данные, сгенерированные пользователем, журналы, потоковые данные реального
времени и т. д. После того как данные будут собраны, их необходимо сохранить
в хранилище данных: базе данных, озере данных, облачном хранилище — в за-
висимости от типа данных и их предполагаемого использования.
После сохранения начинается этап обработки данных и аналитики, в том числе
сортировки, агрегирования или преобразования данных в удобную форму, по-
зволяющую проводить аналитику обработанных данных для получения значи-
мой информации. Аналитика представлена в широком диапазоне, от простых
запросов и отчетов до сложных алгоритмов МО и прогнозного моделирования.
Рассмотрим названные этапы более подробно.
Поглощение данных
Поглощение данных представляет собой сбор данных для их перемещения
и хранения. Существует много источников, из которых данные могут поступать
в систему. Как правило, это базы данных, потоки данных, журналы и файлы.
Самый популярный из этих источников — базы данных. Обычно это транзакци-
онные системы, являющиеся основным хранилищем данных приложений. Они
делятся на реляционные и нереляционные, и существует множество способов
извлечь из них данные.
Потоки данных представляют собой неограниченные последовательности дан-
ных с привязкой по времени (например, данных взаимодействий с веб-сайтов
или устройств интернета вещей, 1оТ), обычно публикуемые при помощи API,
которые вы предоставляете. Приложения, сервисы и операционные системы
генерируют журналы. Как показано на рис. 12.3, для выбора способа поглоще-
ния, идеально подходящего для ваших целей, следует учитывать тип данных,
собираемых средой, и способ их сбора.
Как показано на диаграмме, транзакционное хранилище данных должно быть
способно оперативно сохранять и загружать данные. Конечным пользователям
нужен быстрый и несложный доступ к данным, поэтому серверы приложений
и веб-серверы идеальны для целей поглощения. По тем же причинам базы дан-
ных NoSQL и реляционная система управления базой данных (РСУБД) обычно
лучше всего подходят для этого процесса.
Данные, передаваемые в отдельных файлах, обычно поглощаются с подключен-
ных устройств. Большой объем файловых данных не требует быстрого хранения
и выборки по сравнению с транзакционными данными. Передача файловых
данных часто осуществляется в одном направлении: данные производятся не-
сколькими ресурсами и поглощаются в одном объекте или файловом хранилище
для дальнейшего использования.
446
Глава 12. Инженерия данных для архитектур решений
Транзакционные: база данных для чтения/записи X ‘ Сервер приложения \ База данных
Веб-сервер
Файлы d J 1 Устройства I Датчики мобильных приложений ф J С Y Облачное хранилище
Рис. 12.3. Типы поглощения данных
Для поглощения потоковых данных — например, журналов посещений — требу-
ются соответствующие решения (такие, как Apache Kafka или Fluentd). Apache
Kafka — популярный вариант, предоставляющий надежную функциональность
«публикация — подписка», способную эффективно обрабатывать огромные
объемы данных. Fluentd — еще один инструмент, который можно использовать
для поглощения данных, — известен прежде всего своей функциональностью
агрегирования журналов.
Изначально журналы хранятся в потоковом хранилище (например, Kafka), что
позволяет использовать их для обработки и анализа в реальном времени. Для
долгосрочного хранения журналов лучше использовать низкозатратные реше-
ния — например, хранилища объектов.
Потоковое хранилище отделяет систему сбора (производителей) от системы
обработки (потребителей). Оно формирует долгосрочный буфер для входных
данных. Данные могут обрабатываться, и частоту их подачи можно настроить
в зависимости от потребностей. Рассмотрим некоторые популярные методы
поглощения данных.
Выбор технологии поглощения данных
Рассмотрим некоторые популярные средства поглощения и передачи данных,
распространяемые с открытым исходным кодом.
Apache DistCp: DistCp означает «распределенная копия» (Distributed Сору)
и является частью экосистемы Hadoop. DistCp используется для копирования
Поглощение данных, сохранение, обработка и аналитика 447
больших объемов данных внутри кластера или между кластерами. DistCp обес-
печивает эффективное и быстрое копирование данных за счет использования
функциональности распределения параллельной обработки MapReduce. Ката-
логи и файлы распределяются в задачи отображения для копирования файло-
вых разделов из источника в приемник. DistCp также обеспечивает обработку
ошибок, восстановление и отчеты между кластерами.
Apache Sqoop: является частью экосистемы проекта Hadoop и используется для
передачи данных между Hadoop и реляционными хранилищами данных — на-
пример, РСУБД. Sqoop позволяет импортировать данные из структурирован-
ного хранилища в файловую систему HDFS (Hadoop Distributed File System)
и экспортировать данные из HDFS в структурированное хранилище данных.
Sqoop использует коннекторы плагинов для соединения с реляционными база-
ми данных. Можно применять API расширения Sqoop для построения нового
коннектора или же воспользоваться одним из включенных коннекторов, под-
держивающих обмен данными между Hadoop и стандартными реляционными
системами баз данных.
Apache Flume: Flume — продукт с открытым исходным кодом, используемый
в основном для поглощения больших объемов журнальных данных. Apache
Flume обеспечивает надежный сбор и агрегирование данных в Hadoop и их
распределение. Flume упрощает поглощение потоковых данных и делает воз-
можной аналитику.
Другие проекты с открытым исходным кодом — такие, как Apache Storm и Apache
Samza — позволяют выполнять потоковую передачу для надежной обработки
неограниченных потоков данных.
Поглощение данных в облаке
Процесс поглощения данных в облаке играет важную роль в управлении боль-
шими данными. Три основных провайдера облачных платформ — AWS, GCP
(Google Cloud Platform) и Azure — предоставляют различные сервисы поглоще-
ния данных. Каждый обладает уникальной функциональностью, адаптирован-
ной для конкретных потребностей и объемов данных. Рассмотрим некоторые
специфические особенности трех облачных провайдеров.
• Сервисы поглощения данных AWS:
AWS Direct Connect: предоставляет высокоскоростное приватное сетевое
подключение к AWS, с сокращенной задержкой и повышенной емкостью
канала. Идеально подходит для передачи больших объемов данных и обес-
печивает более стабильную скорость сети, чем передача по интернету;
AWS Snowball и Snowmobile: сервисы предоставляют физические устрой-
ства для передачи в AWS огромных объемов данных (терабайт и петабайт
(Пбайт)). Snowball подходит для передачи сотен терабайт; Snowmobile
может обработать до 100 Пбайт за одну передачу, благодаря чему он иде-
ально подходит для огромных наборов данных;
448 Глава 12. Инженерия данных для архитектур решений
AWS(DMS, Database Migration Service): упрощает миграцию баз данных
в AWS. Поддерживает как гомогенные, так и гетерогенные миграции
и может обеспечивать текущую репликацию данных через механизм от-
слеживания изменений (CDC — change data capture).
• Сервисы поглощения данных GCP:
Google Cloud Storage Transfer Service: позволяет передавать большие
объемы данных в Google Cloud Storage из онлайн-источников данных
(Amazon S3 и HTTP/HTTPS), а также из локальных систем хранения;
Pub/Sub: передача сообщений и поглощение потоковых данных в реаль-
ном времени. Это масштабируемый и гибкий сервис, который позволяет
поглощать потоковые данные (например, журналы и данные событий)
для аналитики в режиме реального времени;
Dataflow: интегрированный сервис для поглощения и обработки данных.
Хорошо подходит для задач извлечения, преобразования, загрузки
(ETL — extract, transform, load) и обработки потоков событий в реальном
времени.
• Сервисы поглощения данных Azure:
Azure Data Factory: этот сервер интеграции данных поддерживает как
локальные, так и облачные перемещения и преобразования данных. Он
позволяет поглощать данные из различных источников, обрабатывать
их с использованием вычислительных сервисов Azure НDinsight и Azure
Batch и публиковать обработанные данные в таких хранилищах данных,
как Azure SQL Data Warehouse;
Azure Event Hubs: надежная и масштабируемая платформа для потоко-
вой передачи данных и сервис поглощения событий. Azure Event Hubs
может обрабатывать миллионы событий в секунду. Благодаря этому он
становится идеальным решением для анализа в реальном времени дан-
ных, поступающих из различных источников: приложений, веб-сайтов,
устройств 1оТ и т. д.;
Azure Import/Export: сервис спроектирован для массовой передачи
больших объемов данных в Azure Blob Storage и Azure Files и обратно.
Он использует физические диски для передачи данных, вследствие чего
подходит для сценариев, когда передача больших объемов данных по сети
может оказаться слишком медленной или затратной.
Каждый облачный провайдер предлагает уникальный набор инструментов для
различных потребностей поглощения данных, от потоковой передачи в реальном
времени до крупномасштабной миграции данных. Таким образом обеспечивается
гибкость и масштабируемость при управлении большими данными.
Задача поглощения и анализа потоковых данных также становится все более
важной. Потоковые данные более подробно рассматриваются в разделе «Хра-
нилища потоковых данных». В нем детально разобраны принципы выбора
правильного хранилища и доступных вариантов хранения.
Поглощение данных, сохранение, обработка и аналитика 449
Хранение данных
Одна из самых распространенных ошибок при настройке хранилища для
больших данных — использование одного решения (часто РСУБД) для всех
требований к хранению данных.
В вашем распоряжении множество инструментов, но их необходимо опти-
мизировать для выполняемой задачи. Одно решение не всегда будет лучшим
для всех потребностей; оптимальным выбором для вашей среды может стать
комбинация решений, соблюдающих баланс между задержкой и затратами.
Идеальное решение — использовать нужный инструмент для нужной задачи.
На рис. 12.4 показаны некоторые характеристики данных и подходящие для
них варианты хранения.
Частота запросов
Высокая <------------------------------------------------------------------------------------------------——> Низкая
Объем данных
Низкая <----------------------------------------------------------------------------------------------------> Высокая
Задержка
Рис. 12.4. Варианты хранения данных
Как показано на диаграмме, выбор хранилища данных зависит от следующих
факторов.
• Насколько данные структурированы? Соответствуют ли они конкретной,
четко сформированной схеме, как веб-логи Apache (логи обычно плохо
структурированы и не подходят для реляционных баз данных), стандар-
тизированные протоколы данных и контрактные интерфейсы? Либо это
произвольные двоичные данные: графика, аудио, видео, документы PDF?
Или это полуструктурированные данные с общей схемой, но потенциально
высокой вариативностью записей, как в JSON или CSV?
• Насколько быстро данные должны становиться доступными для запросов?
Они предполагают сценарий реального времени, в котором решения при-
нимаются при поступлении новых записей (как, например, при настройке
450 Глава 12. Инженерия данных для архитектур решений
рекламной кампании на основе коэффициента конверсии либо генерировании
рекомендаций в интернет-магазине на основе схожего поведения пользовате-
лей)? Или же сценарий с ежедневными, еженедельными либо ежемесячными
пакетами данных, как при обучении моделей, подготовке финансовых отчетов
либо отчетов о производительности продукта? Или это некий промежуточ-
ный вариант, как электронные рассылки для привлечения клиентов? Они
не требуют действий в реальном времени, и между действием пользователя
и точкой взаимодействия может пройти несколько минут или даже часов.
• Какой объем данных необходимо поглощать? Поглощаются ли данные
в том формате, в котором они поступают, — например, JSON от REST API,
записи которого занимают в лучшем случае несколько килобайт? Или это
большой массив записей, поступающих одновременно, — например, поставка
данных системной интеграции или сторонних данных? Или промежуточный
вариант — несколько микропакетов или данных посещений, агрегированных
для более эффективной обработки?
• Каков общий объем данных и скорость его роста? Вы работаете с гига-
байтами, терабайтами или планируете хранить петабайты и даже экзабайты
данных? Какая часть этих данных необходима вам для целей аналитики?
Требует ли большинство ваших запросов конкретного скользящего вре-
менного окна или вам нужен механизм для запроса всего исторического
датасета?
• Каких затрат потребуют хранение и получение данных в любом конкрет-
ном месте? В любой вычислительной среде обычно существует треугольник
ограничений между производительностью, устойчивостью и затратами. Чем
выше желаемая производительность и устойчивость хранилища, тем дороже
оно обойдется. Можно выполнять быстрые запросы к петабайтам данных,
но ограничиться запросами терабайтов данных в сжатом формате для соот-
ветствия требований к затратам.
Наконец, какие аналитические запросы будут отправляться к данным? Будут
ли данные использованы для дашборда с фиксированным набором метрик
и возможной детализацией? Или они потребуются для больших агрегаций,
разворачиваемых по разным бизнес-измерениям? Или будут использоваться
для диагностики с токенизацией строк для полнотекстового поиска и анализа
закономерностей?
После определения характеристик данных и их структуры можно переходить
к оценке решений, которые могут использоваться для хранения данных. Рас-
смотрим их варианты.
Поглощение данных, сохранение, обработка и аналитика 451
Выбор технологии хранения данных
Как уже говорилось, возможности каждого отдельно взятого инструмента огра-
ниченны. Лучше использовать подходящий инструмент для каждой конкретной
задачи, а озеро данных позволяет построить архитектуру Big Data с широкими
возможностями настройки для специфических потребностей.
Так, активно используемые данные должны храниться и обрабатываться в памя-
ти, и для них подходят кэши или базы данных в памяти — например, Redis или
SAP HANA. AWS предлагает сервис ElastiCache, предоставляющий управляе-
мую среду Redis или memcached. Базы данных NoSQL идеально подходят для
быстрых операций с записями небольшого размера — например, информации
о пользовательских сессиях или данных 1оТ. Базы данных NoSQL также полезны
для управления контентом при сохранении каталогов данных.
Рассмотрим самые популярные и часто используемые варианты хранения
структурированных данных.
Хранение структурированных данных
Хранение структурированных данных существует уже много лет; пожалуй, это
самая популярная технология хранения данных. Большинство транзакционных
баз данных — Oracle, MySQL, SQL Server, PostgreSQL и т. д. — работают на
уровне строк данных, что связано с частыми операциями записи из приложений.
Организации часто используют транзакционные базы данных для создания от-
четов, требующих частого чтения и существенно более низкой частоты операций
записи. В отношении частого чтения все больше инноваций внедряется в области
запросов к структурированным хранилищам данных — например, колоночный
формат файлов, способствующий повышению производительности чтения для
целей аналитики.
Строковые форматы хранят данные по строкам. Запись строк данных — самый
быстрый вариант записи данных на диск, но не обязательно самый быстрый
вариант чтения, потому что приходится пропускать большое количество неак-
туальных данных. Колоночные форматы хранят все значения столбцов в одной
части файла. Такое решение повышает эффективность сжатия благодаря груп-
пировке однотипных данных. Производительность чтения также улучшается,
потому что при чтении можно пропускать лишние столбцы.
Рассмотрим популярные варианты хранения структурированных данных. Пред-
ставим, что требуется узнать общий объем продаж за определенный месяц из
таблицы заказов, состоящей из 50 столбцов. В архитектуре, ориентированной
на строки данных, запрос сканирует всю таблицу со всеми 50 столбцами. В ко-
лоночной архитектуре запрос сканирует только столбец с данными о продажах,
что значительно повышает производительность запросов. В следующем разделе
мы подробнее рассмотрим реляционные базы данных, уделяя особое внимание
транзакционным данным и хранению данных для целей аналитики.
452 Глава 12. Инженерия данных для архитектур решений
Реляционные базы данных
РСУБД лучше подходит для приложений с обработкой транзакций в реальном
времени (OLTP). Популярные реляционные базы данных — Oracle, MSSQL,
MariaDB, PostgreSQL и т. д. Некоторые традиционные базы данных существуют
уже десятилетия. Многие приложения, включая интернет-магазины, банковские
приложения и системы бронирования отелей, строятся на основе реляционных
баз данных. Реляционные БД очень хорошо подходят для работы с транзакци-
онными данными, когда необходимы сложные запросы на соединение таблиц.
В том, что касается поддержки транзакционных данных, реляционная БД
должна соблюдать принципы атомарности, согласованности, изолированности
и надежности (ACID).
• Атомарность (Atomicity): транзакция полностью выполняется от начала до
конца, а при возникновении ошибок полностью откатывается.
• Согласованность (Consistency): все данные должны сохраняться в базе дан-
ных при завершении транзакций.
• Изолированность (Isolation): выполняемые одновременно транзакции долж-
ны быть изолированы и не мешать друг другу.
• Надежность (Durability): в случае любых прерываний (например, сбоев
работы сети или питания) транзакция должна продолжиться с последнего
известного состояния.
Данные из реляционных БД часто выгружаются в хранилища данных (data
warehouses) для целей агрегирования и отчетности. В следующем разделе хра-
нилища данных рассматриваются более подробно.
Хранилища данных (data warehouses)
Хранилища данных представляют собой централизованные репозитории для
хранения данных, накопленных из одного или нескольких источников. В них
содержатся текущие и исторические данные, упрощающие создание отчетов для
целей бизнес — аналитики. Хотя в хранилищах есть данные из разных систем,
их нельзя считать озерами данных (data lakes). Хранилища данных работают
только со структурированными реляционными данными, тогда как озера дан-
ных — и со структурированными, и с неструктурированными данными, например
журналами JSON и данными CSV.
Базы данных хранилищ больше подходят для приложений аналитической об-
работки данных в реальном времени (OLAP). Эти БД оптимизированы для
операций, связанных с чтением больших объемов данных, предоставляя воз-
можность агрегирования и обобщения данных для извлечения ценной бизнес-
информации.
Для примера возьмем сценарий с банком, который поддерживает хранилище
данных с подробной информацией о счетах клиентов, транзакциях, условиях
кредитов и филиалах. Кроме того, банк может проводить сложный анализ
Поглощение данных, сохранение, обработка и аналитика 453
объединенных данных. Запросы к хранилищу данных используются для вы-
явления тенденций — например, определения самых популярных типов счетов
или кредитов, анализа объемов транзакций с течением времени или сравнения
шаблонов использования банковских сервисов в отделениях и в онлайн-банке.
Аналитические возможности позволяют банку принимать обоснованные реше-
ния о предложении продуктов, повышении качества обслуживания клиентов
и операционных стратегиях, что в конечном счете повышает удовлетворенность
клиентов и способствует развитию бизнеса.
Хранилища данных предоставляют функциональность быстрого агрегирования
больших объемов структурированных данных. Хотя эти технологии (такие,
как Amazon Redshift, Netezza и Teradata) проектировались для ускоренного
выполнения сложных составных запросов, их необходимо оптимизировать для
больших объемов одновременных операций записи. Таким образом, данные
должны загружаться пакетами, что не позволяет хранилищам данных предо-
ставлять аналитику в реальном времени.
Для повышения производительности запросов современные хранилища ис-
пользуют колоночные базы. Например, Amazon Redshift, Snowlake и Google
BigQuery обеспечивают высокую скорость запросов благодаря колоночному
хранению и улучшенной эффективности ввода/вывода. Кроме того, системы
хранилищ данных типа Amazon Redshift ускоряют обработку запросов за счет
распределенной обработки запросов (параллельное выполнение на нескольких
узлах) и использования массово-параллельной обработки (МРР — massively
parallel processing).
Колоночное хранение повышает производительность запросов — так как данные
хранятся по столбцам, а не по строкам, открывается возможность сжатия дан-
ных, избирательного чтения и ускорения операций. Оно также оптимизирует
использование кэша процессора за счет загрузки в память актуальных данных,
повышая скорость обработки. Кроме того, колоночное хранение поддерживает
массово-параллельную обработку, при которой разные процессоры одновре-
менно работают над разными сегментами данных, значительно повышая про-
изводительность аналитики больших наборов данных, требующей быстрого
агрегирования и фильтрации.
Решения единых хранилищ данных — такие, как Amazon Redshift — способны
обрабатывать петабайты данных и предоставляют изолированную функциональ-
ность вычисления и хранения в целях экономии. Кроме колоночного хранения,
Redshift поддерживает кодирование данных, распределение и карты зон (zone
maps) для повышения производительности запросов. Среди более традицион-
ных инструментов единых хранилищ данных стоит упомянуть Netezza, Teradata
и Greenplum.
Использование единых хранилищ данных влечет за собой физическое отделение
данных от приложений, что обязывает архитекторов данных создавать новые
инфраструктуры на основе единых хранилищ. Ограничения традиционных
454
Глава 12. Инженерия данных для архитектур решений
единых хранилищ данных стали более заметными с ростом разнородности кор-
поративных данных, включающих текст, данные 1оТ, графику, аудио и видео.
Более того, рост популярности МО и искусственного интеллекта (ИИ) вывел
на передний план итеративные алгоритмы, которые требуют прямого доступа
к данным и не полагаются на SQL, тем самым подчеркивая ограниченность
традиционных моделей единых хранилищ данных. О том, как решать эти про-
блемы, вы узнаете далее в этой главе, в разделе «Проектирование архитектур
Big Data».
Базы данных NoSQL
Базы данных NoSQL — такие, как DynamoDB, Cassandra и MongoDB — ре-
шают проблемы масштабирования и производительности, с которыми часто
приходится сталкиваться при работе с реляционными базами данных. Как
следует из названия, базы NoSQL не являются реляционными. В них данные
хранятся без явного структурированного механизма связывания данных из
разных таблиц (отсутствуют соединения, внешние ключи или принудительная
нормализация).
NoSQL использует несколько моделей данных, включая колоночную модель,
пары «ключ — значение», поисковую, документную и графовую модель. Базы
данных NoSQL обеспечивают масштабируемую производительность, высокую
доступность и устойчивость. Как правило, они не требуют жесткой схемы,
и каждый элемент может иметь произвольное количество столбцов (атрибу-
тов). Таким образом, одна строка может состоять из четырех столбцов, а другая
строка той же таблицы — из десяти столбцов. Ключ раздела (partition key)
используется для выборки значений или документов, содержащих связанные
атрибуты. Базы данных NoSQL сильно распределены и могут реплицироваться.
Они долговечны и не сталкиваются с проблемами производительности при
высокой доступности.
Сравнение баз данных SQL и NoSQL
Базы данных SQL существуют уже несколько десятилетий, и многие хорошо
знакомы с реляционными базами данных. Давайте рассмотрим некоторые
принципиальные различия между базами данных SQL и NoSQL (табл. 12.1).
В зависимости от данных для решения конкретных задач в NoSQL используются
различные способы хранения. В следующем разделе рассматриваются основные
виды баз данных No SQL.
Поглощение данных, сохранение, обработка и аналитика 455
Таблица 12.1. Сравнение баз данных SQL и NoSQL
Свойства Базы данных SQL Базы данных NoSQL
Модель данных Реляционная модель норма- лизует данные в таблицы со строками и столбцами. Схема включает таблицы, столбцы, отношения между таблицами, индексы и другие элементы Не требуют наличия фиксирован- ной схемы, обеспечивая гибкость хранения и извлечения данных. Часто используют ключ раздела для обращения к значениям из на- боров столбцов. Эта разновидность БД хорошо подходит для хранения полуструктурированных данных, включая такие форматы, как JSON, XML и другие разновидности до- кументов (например, каталоги дан- ных и файловые индексы)
Транзакция Соответствуют набору свойств ACID транзакционных систем Жертвуют некоторыми свойствами ACID, типичными для традицион- ных РСУБД, для упрощения го- ризонтального масштабирования и повышения гибкости моделей данных
Произво- дитель- ность Использовались для оптими- зации дискового пространства, когда оно стоило дорого, и ми- нимизировали объем хранения. Производительность в основ- ном зависела от диска. Опти- мизация производительности запросов требует создания ин- дексов и изменения структуры таблиц Производительность в большой степени зависит от таких факторов, как размер используемого аппарат- ного кластера, сетевая задержка и схема взаимодействия приложе- ния с базой данных
Масштаби- рование Проще всего масштабируются по вертикали за счет повыше- ния мощности оборудования. Условие охвата распределенных систем (например, при шарди- ровании данных) потребует до- полнительных усилий Проектируются с расчетом на го- ризонтальное масштабирование с использованием распределенных кластеров экономичного оборудо- вания. Такой подход направлен на повышение пропускной способно- сти при минимальном увеличении задержки
456
Глава 12. Инженерия данных для архитектур решений
Виды баз данных NoSQL
Основные разновидности баз данных NoSQL:
• колоночные: Apache Cassandra и Apache HBase — популярные колоночные
базы данных. Колоночное хранилище данных позволяет сканировать при за-
просе конкретный столбец (вместо сканирования всей строки). Представим,
что таблица товарных запасов содержит десять столбцов и один миллион
строк и вы хотите запросить количество имеющихся в наличии товаров.
В таком случае колоночная база данных применит запрос к столбцу с коли-
чеством единиц товара и не будет сканировать всю таблицу;
• документоориентированные: самые популярные в этой категории —
MongoDB, Couchbase, MarkLogic, DynamoDB, DocumentDB и Cassandra.
Такая БД может использоваться для хранения полуструктурированных
данных в форматах J SON и XML;
• графовые: наиболее распространенные графовые базы данных — Amazon
Neptune, Janus Graph, Tinker Pop, Neo4j, OrientDB, GraphDB и GraphX в Spark.
В графовых БД хранятся вершины и связи между вершинами, называемые
ребрами. Графы могут строиться на основе как реляционных, так и нереля-
ционных баз данных;
• хранилища пар «ключ — значение» в памяти: популярные представители
этой категории — Redis и Memcached. Они хранят данные в памяти для
приложений с интенсивным чтением. Любой запрос от приложения сначала
попадает в базу данных в памяти, и, если данные доступны в кэше, нет не-
обходимости обращаться к основной БД. База данных в памяти подходит
для хранения информации пользовательских сессий; к ним обращаются
со сложными запросами и часто запрашивают такие данные, как пользо-
вательские профили.
У баз данных NoSQL много практических применений, но для проведения поис-
ка в них все данные необходимо проиндексировать. В следующем разделе более
подробно рассматриваются поисковые хранилища данных.
Поисковые хранилища данных
Сервис Elasticsearch — одна из самых популярных поисковых систем для боль-
ших данных (например, данных посещений и анализа журналов). Поисковые
системы хорошо работают с «теплыми» данными, которые могут запрашиваться
ситуативно по любому количеству атрибутов, включая строковые токены.
Amazon OpenSearch Service предоставляет функциональность поиска и под-
держку кластеров Elasticsearch с открытым исходным кодом, включая доступ
к API. Также предлагается механизм визуализации Kibana для индексируемых
хранилищ данных. AWS управляет емкостью, масштабированием и коррекцией
кластеров, избавляя от любых накладных расходов на эксплуатацию. Поиск
в журналах и их анализ — популярный сценарий работы с большими данными,
Поглощение данных, сохранение, обработка и аналитика 457
при котором OpenSearch используется для анализа журнальных данных веб-
сайтов, парков серверов, датчиков 1оТ и т. д. OpenSearch и Elasticsearch на-
ходят применения в самых разных отраслях, таких как банковское дело, игры,
маркетинг, мониторинг приложений, рекламные технологии, обнаружение по-
пыток мошенничества, рекомендательные технологии и 1оТ. Также доступны
сервисы поиска на базе машинного обучения — такие, как Amazon Kendra; они
предоставляют продвинутые возможности поиска с использованием обработки
естественных языков (NLP, natural language processing).
Хранилища неструктурированных данных
С точки зрения требований к хранилищам неструктурированных данных
Hadoop — идеальный вариант: эта система хорошо масштабируется, расширя-
ется и обладает исключительной гибкостью. Она может работать на оборудо-
вании потребителя, имеет обширную экосистему инструментов и отличается
экономичностью. Hadoop использует модель главных и дочерних узлов', данные
распределяются между несколькими дочерними узлами, а главный узел коор-
динирует задания для выполнения запросов к данным.
Система Hadoop основана на технологии МРР, что позволяет ей быстро вы-
полнять запросы с данными любых типов — как структурированными, так
и неструктурированными.
При создании кластера Hadoop каждый дочерний узел, создаваемый из сервера,
получает блок присоединенного дискового пространства, называемый локальным
дисковым хранилищем HDFS. Обращаться с запросами к хранимым данным
можно с использованием популярных обрабатывающих фреймворков — таких,
как Hive, Pig и Spark. Однако данные на локальном диске существуют лишь на
протяжении жизни соответствующего экземпляра.
Если вы используете уровень хранения Hadoop (HDFS) для хранения своих
данных, то вы связываете хранение данных с вычислениями. Расширение про-
странства хранения означает добавление новых машин, что также увеличивает
вычислительную емкость. Для достижения максимальной гибкости и эконо-
мичности необходимо отделять вычисления от хранения и масштабировать их
независимо. В целом объектное хранилище больше подходит для эффективного
и экономичного хранения разных типов данных. Облачные озера данных на
базе объектных хранилищ предоставляют необходимую гибкость для отделения
вычислений от хранения. Рассмотрим объектные хранилища более подробно,
Объектное хранилище
Под хранением объектов понимается хранение и обращение к данным в виде
единиц, часто называемых объектами, которые хранятся в бакетах (buckets).
В объектных хранилищах файлы и объекты не разделяются на блоки данных,
но данные и метаданные хранятся вместе. Количество объектов, хранящихся
458 Глава 12. Инженерия данных для архитектур решений
в бакете, неограниченно, а для обращения к ним используются вызовы API
(обычно через HTTP GET или PUT), которые читают или записывают объек-
ты в бакеты. Как правило, объектное хранилище не монтируется как файловая
система в операционной системе, поскольку задержка запросов к файлам через
API и отсутствие блокировки уровня файлов ухудшает производительность.
Объектное хранилище использует масштабирование и плоское пространство
имен, что сокращает расходы на управление и упрощает работу с метаданными.
Объектные хранилища стали более популярными в публичном облаке, и именно
они обычно применяются для создания облачных масштабируемых озер данных.
Самые популярные варианты объектных хранилищ — Amazon S3, Azure Blob
Storage и Google Cloud Storage в GCP.
Векторные базы данных (VectorDB)
Векторные базы данных стали очень популярными в последнее время благодаря
растущему вниманию к генеративному ИИ и МО. Под векторными данными
обычно понимаются многомерные точки данных, часто используемые в контексте
моделей МО. Например, изображение, текст или аудиофайл можно преобразо-
вать в векторное представление (список чисел), которое отражает важнейшие
характеристики оригинала. Эти векторы используются в таких задачах МО,
как поиск по подобию (нахождение самых похожих элементов), группировка
или классификация. Например, если вы хотите построить систему классифи-
кации клиентов, векторные эмбеддинги могут использоваться для кластериза-
ции клиентов на группы в зависимости от их покупательского поведения или
предпочтений. Анализируя векторные представления историй покупок или
взаимодействий с веб-сайтом, можно идентифицировать отдельные группы
похожих клиентов. Это позволяет адаптировать рыночные стратегии, выдавать
персонализированные предложения или целенаправленно разрабатывать про-
дукты для конкретных групп, что способствует повышению удовлетворенности
и лояльности клиентов.
Векторные базы данных представляют развивающуюся категорию баз данных,
в основном сосредоточенных на эффективной работе с векторными данными.
Этот тип данных часто ассоциируется с МО — обычно в таких областях, как
распознавание образов, NLP и рекомендательные системы.
Основная функциональность векторной базы данных — эффективное хранение
векторных данных и управление ими. Это подразумевает механизм хранения
многомерных точек данных и оптимизацию архитектуры базы данных для под-
держки быстрых и эффективных запросов, часто в форме поиска ближайших
соседей.
Современные векторные базы данных могут внедрять модели МО прямо в базу
данных. Это позволяет преобразовывать необработанные данные (например,
графику или текст) в векторы «на лету», после чего эти векторы можно сохра-
нять и обращаться к ним с запросами.
Поглощение данных, сохранение, обработка и аналитика 459
Стандартный сценарий использования — поиск элементов, похожих на заданный
элемент. Например, база данных может быстро вернуть изображения, сходные
с изображением из запроса. Векторные базы данных могут обеспечивать работу
рекомендательных систем, сопоставляя профили пользователей с векторами про-
дуктов, чтобы порекомендовать подходящие элементы. Они могут эффективно
обрабатывать и запрашивать крупномасштабные текстовые данные, преобра-
зованные в векторное пространство для применения в сфере NLP. Основные
преимущества векторных баз данных:
• скорость и эффективность: векторные БД, адаптированные для работы
с многомерными данными, могут выполнять поиск по подобию намного
быстрее, чем традиционные базы данных;
• масштабируемость: векторные БД проектируются для масштабирования по
размеру данных. Это очень важно для приложений МО, в которых обычно
используются очень большие наборы данных;
• интеграция с пайплайнами MO/ИИ: бесшовная интеграция с потоками
операций МО, разрешающая прямые запросы к векторным данным и мани-
пуляции с ними.
Впрочем, у векторных баз данных имеются и недостатки:
• сложность: управление и индексирование многомерных векторных данных
могут быть достаточно непростой задачей;
• ресурсоемкость: такие базы данных могут требовать значительных вычис-
лительных ресурсов, особенно для больших наборов данных;
• недостаточная зрелость технологии: векторные базы данных появились
относительно недавно, поэтому экосистема вокруг них может быть не такой
зрелой, как у традиционных баз данных, что может повлиять на решение
о внедрении в корпоративных средах.
Векторные БД являются частью более широкой тенденции к использованию
специализированных баз данных, адаптированных для конкретных типов данных
и рабочих нагрузок, особенно в контексте МО и ИИ. Они представляют собой
важный этап в развитии технологий баз данных, которые стремятся не отставать
от достижений в области обработки данных и аналитики. По мере становления
эта технология с большой вероятностью станет неотъемлемой частью инфра-
структуры данных в организациях со значительными вложениями в МО и ИИ.
Хранилище блокчейн-данных
Технология блокчейна, обычно ассоциируемая с криптовалютами, предлагает
революционный подход к управлению данными и обработке транзакций в раз-
личных отраслях, не только в финансах. Хранилища блокчейн-данных предо-
ставляют мощный механизм децентрализованной проверки данных, который, по
сути, принципиально меняет подход к сохранению и проверке транзакций в раз-
ных отраслях. Например, в кадастровой системе на базе блокчейн-технологий
460 Глава 12. Инженерия данных для архитектур решений
каждая операция продажи или покупки недвижимости регистрируется в общем
реестре и мгновенно становится доступной и проверяемой для всех сетевых
участников. Такая прозрачность отличается от традиционных централизованных
систем, где данными управляет один авторитетный источник; она снижает риск
мошенничества и повышает доверие между участниками.
Основные характеристики блокчейна — неизменяемость и безопасность — расширя-
ют возможности его применения между отраслями. Например, в здравоохранении
блокчейн гарантирует, что после ввода данных пациента в систему эти данные оста-
нутся неизменными и безопасными. Такая неизменяемость чрезвычайно важна для
профессиональных медиков, которые выбирают курс лечения, полагаясь на точные
исторические данные. Кроме того, криптографическая безопасность блокчейна
защищает чувствительную информацию о здоровье, предоставляя доступ только
авторизованным пользователям и обеспечивая конфиденциальность пациентов.
Благодаря этим свойствам блокчейн становится бесценным инструментом в тех
отраслях, где особенно важны целостность и безопасность данных.
В достижении неизменяемости ключевую роль играют сети блокчейна. Факти-
чески они превращаются в децентрализованный цифровой реестр, в котором
регистрируются транзакции от разных компьютеров; при этом используется ме-
ханизм, обеспечивающий целостность и безопасность данных. В блокчейн-сетях
транзакции группируются в блоки; каждый блок связывается с предыдущим,
образуя цепочку. Такая структура значительно усложняет изменение информа-
ции задним числом без согласия всех сетевых участников. Ниже перечислены
основные разновидности блокчейн-сетей.
• Публичные блокчейн-сети: Ethereum часто используется для децентра-
лизованных приложений (DApps) и смарт-контрактов. Сеть Ethereum яв-
ляется открытой, любой желающий может присоединиться и участвовать
в ее работе. Например, разработчик может создать DApp-приложение для
децентрализованных финансов (DeFi) в сети Ethereum, давая возможность
пользователям участвовать в финансовых транзакциях без привлечения
традиционных банков.
• Частные блокчейн-сети: доступ к сетям этого типа ограничен. Их работой
управляет организация, предоставляя большую степень конфиденциально-
сти и контроля. Фармацевтическая компания может использовать частную
блокчейн-сеть для управления процессом производства лекарств. Доступ
к блокчейну ограничивается исследователями и надзорными органами, что
обеспечивает конфиденциальность чувствительных данных.
• Блокчейн-сети консорциумов: блокчейн-сети, находящиеся под управлением
нескольких организаций и сохраняющие баланс между децентрализацией
и управлением. Пример — группа компаний-перевозчиков, сформировавших
консорциум для управления общей блокчейн-сетью. Эта блокчейн-сеть может
использоваться для отслеживания грузов по всему миру, при этом каждая
компания будет поддерживать свой узел в этой сети.
Поглощение данных, сохранение, обработка и аналитика 461
Такие облачные провайдеры, как AWS, предлагают блокчейн как сервис, упрощая
настройку блокчейн-сетей и управление ими. Amazon QLDB (Quantum Ledger
Database) — пример централизованной базы данных-реестра, предоставляющей
неизменяемый и криптографически проверяемый протокол транзакций. По-
пулярные управляемые блокчейн-сервисы, включая AM В (Amazon Managed
Blockchain), R3 Corda, Ethereum и Hyperledger, обслуживают различные по-
требности — от финансовых транзакций до управления цепочками поставок.
Обработка потоковых данных когда-то считалась нишевой технологией, но
сейчас ее популярность растет, поскольку каждая организация сталкивается
с задачей быстрого получения аналитической информации после обработки
данных в реальном времени. В следующем разделе хранилища потоковых данных
рассматриваются более подробно.
Хранилища потоковых данных
Потоковые данные поступают непрерывно, без начала и конца. Большой объем
данных от различных ресурсов реального времени (биржевые котировки, бес-
пилотные автомобили, умные дома, социальные сети, электронная коммерция,
игры, приложения для поездок и т. д.) необходимо быстро сохранять и обраба-
тывать. Netflix предоставляет рекомендации в реальном времени на основании
просматриваемого контента, a Lyft использует потоковые данные для связи
пассажиров с водителем в реальном времени.
Хранение и обработка потоковых данных — непростая задача, поскольку в си-
стему поступает непрерывный поток данных и емкость хранилища невозможно
предсказать заранее. Наряду с большим объемом, потоковые данные харак-
теризуются очень высокой скоростью; это требует масштабируемой системы
хранения, которая способна хранить данные и предоставлять средства для
их воспроизведения. Со временем потоки данных начинают требовать очень
высоких затрат на обслуживание и высокой сложности управления. Самые
популярные сервисы хранения потоковых данных — Apache Kafka, Apache
Flink, Apache Spark Structured Streaming, Apache Samza и Amazon Kinesis. AWS
предоставляет управляемую разновидность Kafka, называемую Amazon Managed
Streaming for Kafka. Рассмотрим подробнее технологии поглощения и хранения
потоковых данных.
• Amazon Kinesis предоставляет три основных сервиса:
KDS (Kinesis Data Streams) используется для хранения необработанного
потока данных для выполнения последующей обработки нужных записей;
KDF (Kinesis Data Firehose) упрощает перемещение записей в общие
аналитические среды: Amazon S3, Elasticsearch, Redshift, Splunk и т. д.
Firehose автоматически буферизует все записи в потоке и сбрасывает его
в приемник как один файл или набор записей в зависимости от порога
по времени или размеру записи, который можно настроить (или того,
который будет достигнут первым);
ЬЬ2 Глава 12. Инженерия данных для архитектур решений
KDA (Kinesis Data Analytics) сначала проводит аналитику потоко-
вых записей с использованием Apache Flink. Вывод может переходить
в другие потоки, создаваемые для построения бессерверного потокового
пайплайна.
• Amazon MSK (Managed Streaming for Kafka) — полностью управляемый
безопасный сервис с высокой доступностью. Amazon MSK выполняет
приложения Apache Kafka в облаке AWS, при этом опыт управления
инфраструктурой Apache не нужен. Amazon MSK предоставляет управ-
ляемый кластер Apache Kafka с кластером ZooKeeper для управления
конфигурацией и создания производителя/потребителя для поглощения
и обработки данных.
• Apache Flink — еще одна платформа с открытым исходным кодом для по-
токовой передачи данных и обработки пакетных данных. Flink представляет
собой ядро потоковой передачи, которое может обрабатывать ограниченные
и неограниченные потоки данных. У ограниченного потока данных опре-
делены начало и конец, а у неограниченного имеется начало, но нет конца.
Flink может выполнять пакетную обработку в своем потоковом ядре и под-
держивает оптимизации пакетов.
• Apache Spark Streaming обеспечивает поглощение живых потоков данных
с высокой пропускной способностью, отказоустойчивостью и масштабируе-
мостью. Spark Streaming разделяет входные потоки данных на пакеты, прежде
чем отправлять их ядру Spark для обработки. Spark Streaming использует
абстракции D Stream — последовательности устойчивых распределенных
наборов данных (RDD, Resilient Distributed Dataset).
• Apache Kafka — одна из самых популярных потоковых платформ с открытым
исходным кодом, которая обеспечивает публикацию потока данных и под-
писку на него. Кластер Kafka сохраняет поток в топике Kafka. Производитель
может публиковать данные в топике Kafka, а потребители — извлекать вы-
ходной поток данных путем подписки на топик Kafka.
Потоковое хранилище должно сохранять непрерывный поток данных и под-
держивать возможность сохранения исходного порядка в случае необходимо-
сти. Потоковые архитектуры более подробно рассматриваются далее в разделе
«Архитектура потоковых данных».
Хранение данных в облаке
Облачные хранилища данных являются одним из важнейших аспектов совре-
менной IT-инфраструктуры. Они отличаются масштабируемостью, гибкостью
и экономичностью. Ведущие провайдеры облачных платформ — AWS, GCP
и Azure — предоставляют различные варианты хранения данных для разных
потребностей, от простого хранения файлов до сложных баз данных и решений
единых хранилищ данных. Ниже перечислены ключевые характеристики об-
лачных хранилищ данных на этих платформах.
Хранение данных в облаке 463
• AWS:
Amazon S3 (Simple Storage Service): высокомасштабируемый сервис
хранения объектов, известный своей высокой доступностью данных,
безопасностью и производительностью. Сервис Amazon S3 гибок, он иде-
ально подходит для хранения любого объема данных, применимых в са-
мых разных сценариях: веб-сайтах, мобильных приложениях, резервном
копировании и восстановлении, архивации, корпоративных приложениях,
устройствах 1оТ и аналитике больших данных.
Amazon EBS (Elastic Block Store): EBS предлагает тома блокового уровня
для использования с экземплярами ЕС2. Они особенно хорошо подхо-
дят для данных, требующих стабильной производительности с низкой
задержкой — например, баз данных или систем планирования ресурсов
предприятия (ERP, Enterprise Resource Planning).
Amazon RDS (Relational Database Service): RDS упрощает настройку,
эксплуатацию и масштабирование реляционной базы данных в облаке.
Сервис предлагает экономичное решение с изменяемой емкостью, а также
автоматизацию многих времязатратных задач администрирования баз
данных.
Amazon S3 Glacier: сервис предоставляет безопасное, надежное и низкоза-
тратное облачное хранилище для архивации и долгосрочного резервного
копирования. Amazon S3 Glacier идеально подходит для хранения данных,
к которым обращаются относительно редко; таким образом, это решение
ориентировано на данные с большим периодом удержания.
• GCP:
Google Cloud Storage: объектное хранилище для компаний любого
размера. Решение обладает высокой масштабируемостью и гибкостью,
предоставляя безопасное и долгосрочное хранилище для приложений
и рабочих нагрузок с повышенным спросом.
Persistent Disk: блоковое хранилище для экземпляров Google Compute
Engine. Предоставляет высокопроизводительное пространство SSD
и HDD, которое может присоединяться к экземплярам, работающим
в Compute Engine или GKE (Google Kubernetes Engine).
Cloud SQL: полностью управляемый сервис баз данных, упрощающий на-
стройку, обслуживание, управление и администрирование реляционных
баз данных в Google Cloud.
Google Cloud Bigtable: масштабируемый, полностью управляемый сервис
баз данных No SQL для больших аналитических и эксплуатационных
рабочих нагрузок.
• Microsoft Azure:
Azure Blob Storage: объектное хранилище Azure, спроектированное для
облачной среды. Оно отлично подходит для хранения больших объемов
неструктурированных данных — например, текстовых или двоичных.
ш
Глава 12. Инженерия данных для архитектур решений
К ним относятся разные виды контента: документы, файлы мультимедиа,
резервные копии и журналы. Таким образом, это хранилище отличается
исключительной гибкостью для широкого диапазона применений.
Azure File Storage: предоставляет облачные, полностью управляемые
общие файловые ресурсы, доступные по стандартному протоколу SMB.
Сервис особенно удобен для бизнеса, желающего перенести свои суще-
ствующие локальные общие файловые ресурсы в облачную среду.
Azure SQL Database: всеобъемлющий, полностью управляемый сервис
реляционных баз данных в облаке. Предоставляет функциональность
SQL Server, но без потребности в обширной инфраструктуре и задачах
администрирования баз данных, что упрощает управление.
Azure Disk Storage: предоставляет высокопроизводительное надежное
блоковое хранилище для Azure Virtual Machines. Azure Disk Storage
включает варианты как с SSD, так и с HDD, вследствие чего подходит
для широкого диапазона требований — от высокой производительности
до экономичности.
Сервисы облачного хранения данных на этих платформах спроектированы так,
чтобы предоставлять безопасные, масштабируемые и доступные решения для
разных применений и сценариев использования. У каждого сервиса есть свои
преимущества, которые делают его подходящим для тех или иных требований
к производительности, масштабированию, доступности данных и затратам.
После поглощения и сохранения данных важно обработать их в удобном формате,
чтобы их можно было визуализировать для целей бизнес-аналитики. В следую-
щем разделе тема обработки и преобразования данных рассматривается более
подробно.
Обработка данных и аналитика
Аналитикой данных называется процесс поглощения, преобразования и визуа-
лизации данных с целью получения ценных инсайтов, используемых в бизнес-
решениях. За последнее десятилетие в мире было собрано больше данных,
чем за все время до этого, и клиенты (компании) стремятся к более глубокому
анализу информации.
Кроме того, результаты обработки данных требуется получать как можно бы-
стрее, иногда даже в реальном времени. Клиентам нужна поддержка ситуатив-
ных (ad hoc) запросов, чтобы решать разнообразные бизнес-задачи. Для этого
требуются мощные и эффективные системы обработки данных.
Пакетная обработка обычно включает запросы больших объемов холодных дан-
ных. При пакетной обработке на получение ответов на вопросы бизнеса могут
уйти часы. Например, пакетная обработка может использоваться для генери-
рования отчетов по выставленным счетам за месяц. Обработка потоков данных
в реальном времени обычно подразумевает запросы небольших объемов горячих
Хранение данных в облаке 465
данных и быстрое получение ответов. Системы на базе MapReduce — такие, как
Hadoop — являются примерами платформ, поддерживающих пакетные задания,
тогда как единые хранилища данных относятся к платформам с поддержкой
ядер запросов.
Обработка потоковых данных предполагает последовательное получение дан-
ных и инкрементное обновление функций в ответ на каждую новую запись. Как
правило, они поглощают непрерывно производимые потоки записей данных
(например, данные от датчиков, данные мониторинга, журналы аудита, журналы
отладки, истории посещений сайтов и события отслеживания для устройств,
людей и физических объектов).
На рис. 12.5 изображен пайплайн озера данных для обработки, преобразования
и визуализации данных с использованием технологического стека облачной
платформы AWS.
Источник данных Amazon S3 Amazon EMR
Необработанные
данные
Amazon S3
Redshift
4
Amazon
Quick Sight
♦
Amazon
Athena
Обработанные
данные
Amazon
Athena
Рис. 12.5. Пайплайн ETL озера данных для обработки Big Data
На диаграмме пайплайн ETL использует Amazon Athena для ситуативных за-
просов к данным, хранящимся в Amazon S3. Данные, поглощенные из разных
источников (например, серверов веб-приложений), генерируют файлы журналов,
сохраняемые в S3. Затем эти файлы преобразуются в заданную форму, необходи-
мую для извлечения значимых результатов, при помощи Amazon EMR (Elastic
MapReduce), после чего загружаются в Amazon S3. Amazon EMR предоставляет
управляемый сервер Hadoop в облаке для обработки данных с использованием
технологий с открытым исходным кодом — таких, как Hive, Pig и Spark.
Преобразованные файлы загружаются в Amazon Redshift командой COPY
и визуализируются с использованием Amazon QuickSight. При помощи Amazon
Athena можно запросить данные непосредственно из Amazon S3 при сохранении
466
Глава 12. Инженерия данных для архитектур решений
данных и после преобразования (с агрегированными датасетами). Для визуализа-
ции данных из Athena можно воспользоваться Amazon QuickSight. К этим файлам
легко обращаться с запросами без изменения существующего потока данных.
В следующем разделе рассматриваются популярные инструменты обработки
данных.
Выбор технологии для обработки и анализа данных
Ниже перечислены самые популярные технологии обработки данных, которые
применяются для выполнения преобразований и обработки Big Data.
• Apache Hadoop использует распределенную архитектуру обработки, в ко-
торой задача передается кластеру серверов. Каждая часть работы, распреде-
ленной на серверы кластера, может выполняться и повторно выполняться на
любом сервере. Серверы кластера часто используют HDFS для локального
хранения обрабатываемых данных. Фреймворк Hadoop берет большое за-
дание, разбивает его на отдельные задачи и обрабатывает их параллельно.
Он обеспечивает массовую масштабируемость по огромному количеству
кластеров Hadoop. Система спроектирована для отказоустойчивости, и каж-
дый рабочий узел периодически сообщает свой статус первичному узлу.
Первичный узел может перераспределять работу из кластера, от которого
не был получен положительный ответ. Самые популярные фреймворки, ис-
пользуемые с Hadoop, — Hive, Presto, Pig и Spark.
• Apache Spark — фреймворк обработки данных в памяти. Apache Spark
представляет собой систему массово-параллельной обработки с разными
исполнителями, которые могут разобрать задание Spark на задачи и выпол-
нять их параллельно. Чтобы повысить параллелизм задания, добавьте узлы
в кластер. Spark поддерживает пакетные, интерактивные и потоковые источ-
ники данных, использует направленные ациклические графы (DAG, directed
acyclic graphs) для представлений стадий во время выполнения работы.
D AG отслеживает данные и преобразования наследования между заданиями
и эффективно минимизирует ввод/вывод за счет хранения кадров данных
в памяти. Spark также поддерживает секционирование для предотвращения
лишних передач данных, создающих нагрузку на сеть.
• (HUE, Hadoop User Experience) позволяет запускать запросы и скрипты в кла-
стере через пользовательский интерфейс (UI) в браузере вместо командной
строки. HUE предоставляет самые популярные компоненты Hadoop в UI.
Таким образом появляется возможность просмотра и отслеживания операций
Hadoop в браузере. Разные пользователи могут обращаться к кластеру через
портал входа HUE, и администраторы могут управлять доступом вручную или
при помощи аутентификации LDAP (Lightweight Directory Access Protocol),
PAM (Pluggable Authentication Modules), SPNE-GO (Simple and Protected
GSSAPI Negotiation Mechanism), OpenlD, OAuth и SAML2 (Security Assertion
Markup Language 2.0). HUE позволяет просматривать журналы в реальном
Хранение данных в облаке 467
времени и предоставляет менеджер метахранилища для манипуляций с со-
держимым метахранилища Hive.
• Pig обычно используется для обработки больших объемов необработанных
данных перед сохранением их в структурированном формате (таблицы
SQL). Pig хорошо подходит для операций ETL — таких, как проверка, за-
грузка, преобразование и объединение данных от нескольких источников
в разных форматах. Помимо ETL, Pig поддерживает реляционные операции:
вложенные данные, соединения и группировку. Скрипты Pig позволяют
вводить неструктурированные и полу структурированные данные (например,
журналы веб-серверов или журналы посещений). С другой стороны, Hive
последовательно требует соблюдения схемы для входных данных. Скрипты
Pig Latin содержат инструкции по фильтрации, группировке и соединению
данных, но Pig не проектировался как язык запросов, для запросов данных
лучше подходит Hive. Скрипт Pig компилируется и запускается для преоб-
разования данных на основании инструкций из скрипта Pig Latin.
• Hive — единое хранилище данных с открытым исходным кодом и пакет за-
просов, работающий на базе кластера Hadoop. Возможность использования
SQL — навык, упрощающий переход к работе с Big Data. Hive использует
SQL-подобный язык, называемый HQL (Hive Query Language), на котором
удобно легко запрашивать и обрабатывать данные в системе Hadoop. Hive
абстрагирует сложность написания программ на таких языках программи-
рования, как Java, для выполнения заданий аналитики.
• Presto — ядро запросов, похожее на Hive, но работающее намного быстрее.
Оно поддерживает стандарт ANSI (American National Standards Institute) SQL,
который легко изучается и входит в самый востребованный набор навыков.
Presto поддерживает сложные запросы, соединения и функции агрегирова-
ния. В отличие от Hive или MapReduce, Presto выполняет запросы в памяти,
что способствует сокращению задержки и повышению производительности
запросов. Будьте внимательны при выборе емкости сервера для Presto, так
как он должен иметь большой объем памяти. Задание Presto перезапускается
по событию переполнения памяти.
• HBase — база данных NoSQL, разработанная как часть проекта Hadoop с от-
крытым исходным кодом. HBase выполняется на HDFS для предоставления
функциональности нереляционных баз данных в экосистеме Hadoop. HBase
помогает хранить большие объемы данных в колоночном формате со сжа-
тием. Кроме того, HBase обеспечивает быстрый поиск, поскольку большие
части кэша данных хранятся в памяти, пока память экземпляра кластера
продолжает использоваться.
• Apache Zeppelin — веб-редактор для аналитики данных, построенный на
базе системы Hadoop; также известен как «блокнот Zeppelin» (Zeppelin
notebook). В нем используется концепция интерпретатора бэкенд-языка, что
теоретически позволяет подключить к Zeppelin любой язык. Apache Zeppelin
468 Глава 12. Инженерия данных для архитектур решений
включает некоторые базовые разновидности диаграмм. Система чрезвычайно
гибка в отношении произвольного вывода от бэкенда любого языка вывода,
который можно распознавать и визуализировать.
• Ganglia — инструмент мониторинга кластеров Hadoop. Для применения
необходимо установить его в кластере при запуске. Ganglia UI работает на
первичном узле, для него можно использовать туннель SSH. Ganglia — проект
с открытым исходным кодом, разработанный для мониторинга кластеров без
влияния на их производительность. С помощью Ganglia можно исследовать
производительность отдельных серверов кластера и кластеров в целом.
• JupyterHub — многопользовательский вариант Jupyter. Jupyter Notebook —
один из самых популярных инструментов среди специалистов в области
данных для целей инженерии данных и МО. Сервер JupyterHub предо-
ставляет каждому пользователю веб-IDE Jupyter Notebook. Пользователи
могут одновременно писать и выполнять код в своих блокнотах Jupyter для
исследовательской аналитики данных.
Обработка данных в облаке
Обработка данных в облаке — фундамент современных стратегий Big Data и ана-
литики. Три основных провайдера облачных сервисов — AWS, GCP и Azure —
предоставляют различные сервисы обработки данных, каждый из которых
обладает своими возможностями и функциональностью. Ниже перечислены
некоторые отличительные особенности каждого варианта.
• AWS Data Processing Services:
Amazon EMR: предоставляет облачно-ориентированную среду Hadoop
с поддержкой широкого спектра фреймворков Big Data, включая Apache
Spark, Hadoop, HBase и Presto. EMR идеально подходит для обработки
больших наборов данных и обеспечивает необходимую гибкость путем
отделения вычислений от хранения, открывая возможность экономичного
масштабирования.
AWS Glue: полностью управляемый сервис ETL, упрощающий подготовку
данных для аналитики. Автоматизирует громоздкую работу по подготовке
данных, генерирует сценарии ETL и упрощает перемещение данных между
сервисами AWS. Glue особенно эффективен для составления каталогов
данных и планирования заданий.
Amazon Athena: бессерверный интерактивный сервис запросов, который
позволяет выполнять запросы SQL непосредственно с данными, храня-
щимися в Amazon S3. Чрезвычайно полезен для ситуативного анализа
данных и запросов BI без требований к управлению инфраструктурой.
• GCP Data Processing Services:
Google BigQuery: полностью управляемое бессерверное решение единого
хранилища данных, спроектированное для быстрого и экономичного вы-
полнения запросов SQL к большим наборам данных. Сервис BigQuery
Хранение данных в облаке 469
особенно ориентирован на аналитику в реальном времени и может эф-
фективно обрабатывать потоковые данные.
Cloud Dataflow: полностью управляемый сервис, предназначенный для
обработки данных в потоковом и пакетном режиме. Сервис, построенный
на базе Apache Beam, предлагает унифицированную модель программи-
рования, упрощающую разработку пайплайнов параллельной обработки
данных. Он хорошо подходит для обработки широкого спектра задач от
разных процессов ETL для пакетных рабочих нагрузок и потоковых ра-
бочих нагрузок реального времени.
Cloud Dataprep: продвинутый сервис данных, предоставляющий воз-
можности для визуального исследования, очистки и подготовки как
структурированных, так и неструктурированных данных для анализа.
Сервис CloudDataprep, бесшовно интегрирующийся с BigQuery и Cloud
Dataflow, расширяет возможности исследования и преобразования
данных.
• Azure Data Processing Services:
Azure HDInsight: полностью управляемый облачный сервис, упрощаю-
щий обработку больших объемов данных популярными фреймворками
с открытым исходным кодом — такими, как Apache, Hadoop, Spark, Kafka
и HBase. Подходит для разных сценариев — ETL, единых хранилищ дан-
ных, МО, 1оТ и т. д.
Azure Databricks: быстрая и простая аналитическая платформа на базе
Apache Spark, ориентированная на совместную работу. Глубоко интегри-
руется с другими сервисами Azure и предоставляет унифицированную
платформу для процессов ETL, потоковой аналитики, МО и единых
хранилищ данных.
Azure Synapse Analytics: всеобъемлющий аналитический сервис, объ-
единяющий функциональность Big Data с хранилищами данных. Предо-
ставляет целостный опыт работы по поглощению, подготовке, управлению
и поставке данных для приложений бизнес-аналитики и МО. Azure Synapse
Analytics делает возможными одновременные запросы к озерам и базам
данных, упрощая процессы анализа.
Сервисы обработки данных каждого облачного провайдера проектировались
для удовлетворения конкретных потребностей в жизненном цикле данных, от
обработки и преобразования больших наборов данных до интерактивных за-
просов и аналитики реального времени. Благодаря такому разнообразию бизнес
может выбрать наиболее подходящие инструменты и платформы в зависимости
от своих специфических потребностей в обработке данных и целей.
Анализ и обработка данных — обширные темы, требующие отдельной книги.
В этом разделе приведен общий обзор популярных и распространенных ин-
струментов обработки. Существует и большое количество других инструментов,
как проприетарных, так и распространяемых с открытым исходным кодом.
470 Глава 12. Инженерия данных для архитектур решений
Вы, как архитектор решений, должны иметь о них представление, чтобы подо-
брать подходящий для вашей организации.
Бизнес-аналитикам требуется создавать отчеты и дашборды, выполнять си-
туативные (ad hoc) запросы и проводить анализ результатов, чтобы получать
ценные инсайты. Тема визуализации данных более подробно рассматривается
в следующем разделе.
Визуализация данных
Аналитика данных используется для ответа на ключевые бизнес-вопросы: вы-
ручка по клиентам, прибыль по регионам, реферальный трафик с рекламных
площадок и т. д. В пайплайне Big Data огромные объемы данных собираются из
разных источников. Компаниям важно также получать информацию о запасах
товаров по регионам, прибыльности и величине потерь от мошенничества. Не-
которые данные, непрерывно собираемые для целей комплаенса, также могут
использоваться для генерирования бизнес-выводов.
Две самые важные проблемы инструментов бизнес-аналитики — стоимость
реализации решений и время, затраченное на нее. Рассмотрим некоторые тех-
нологии визуализации данных.
Технологии визуализации данных
Ниже перечислены некоторые популярные платформы визуализации данных,
которые помогут подготовить отчеты с наглядным представлением данных в со-
ответствии с требованиями бизнеса
• Amazon QuickSight — облачный инструмент бизнес-аналитики для визуа-
лизации данных корпоративного уровня. Поставляется с разнообразными
шаблонами графиков и диаграмм: линейными графиками, круговыми диа-
граммами, древовидными картами, тепловыми картами, гистограммами
и т. д. Amazon QuickSight использует ядро кэширования SPICE (Super-
fast, Parallel, In-memory Calculation Engine), которое ускоряет создание
визуализаций. Также поддерживаются операции подготовки данных:
переименование и удаление полей, изменение типов данных и создание
новых вычисляемых полей. QuickSight также предоставляет визуализа-
ции на базе результатов МО и другие функции на базе МО — например,
автопрогнозирование.
• Kibana — инструмент визуализации данных, распространяемый с откры-
тым исходным кодом. Применяется для визуализации потоковых данных
и анализа журналов. Kibana предоставляет интеграцию с Elasticsearch и ис-
пользует ее по умолчанию для поиска данных на базе сервиса Elasticsearch.
Как и другие инструменты бизнес-аналитики, Kibana предлагает популярные
средства визуализации: гистограммы, круговые диаграммы, тепловые карты
и т. д., а также встроенную геопространственную поддержку.
Проектирование архитектур Big Data 471
• Tableau — один из самых популярных инструментов бизнес-аналитики для
визуализации данных. В нем используется ядро визуальных запросов, оп-
тимизированное таким образом, чтобы большие данные анализировались
быстрее традиционных запросов. Tableau предоставляет интерфейс, основан-
ный на перетаскивании элементов (drag-and-drop), и возможность слияния
данных из нескольких ресурсов.
• Spotfire выполняет обработку в памяти для ускорения ответа, поддерживая
обширные наборы данных из разных ресурсов. Spotfire позволяет нанести
данные на географическую карту и опубликовать ее в Twitter. Если вклю-
чить рекомендации Spotfire, система автоматически проанализирует данные
и предложит лучший вариант их визуализации.
• Jaspersoft поддерживает отчеты и аналитику самообслуживания. Также
поддерживается визуальный конструктор, основанный на перетаскивании
(drag-and-drop).
• Power BI — популярный инструмент бизнес-аналитики от компании
Microsoft. Он предоставляет возможности аналитики самообслуживания
с различными вариантами визуализации.
Визуализация данных — исключительно важная и обширная тема. Вы, как ар-
хитектор решений, должны разбираться в доступных инструментах и выбирать
такое решение визуализации данных, которое наилучшим образом подходит для
ваших бизнес-требований.
Вы познакомились с компонентами пайплайнов данных, от поглощения, хра-
нения и обработки до визуализации. В следующем разделе мы объединим эти
компоненты, и вы узнаете, как оркестрировать архитектуру Big Data.
Проектирование архитектур Big Data
Big Data-решения включают функции поглощения данных, преобразования для
хранения, обработки и визуализации. В повседневных бизнес-операциях этапы
повторяются. Для выстраивания этих рабочих процессов можно использовать
технологии с открытым исходным кодом или облачные технологии, о которых
вы узнали в предыдущих разделах.
Сначала необходимо понять, какой архитектурный стиль подходит для вас;
для этого необходимо двинуться в обратном направлении от бизнес-сценария.
Рекомендуется составить представление о конечном пользователе своей архи-
тектуры Big Data и создать условного персонажа; это поможет лучше понять
требования. Чтобы определить ключевых целевых персонажей для архитектуры
данных, необходимо ответить на следующие вопросы.
• В каких командах, отделах или подразделениях организации они работают?
• Каким уровнем квалификации в области анализа и инженерии данных они
обладают?
• Какими инструментами они обычно пользуются?
472 Глава 12. Инженерия данных для архитектур решений
• Следует ли ориентироваться на работников, клиентов или партнеров орга-
низации?
Если взять для примера анализ торговой сети, можно определить следующих
персонажей.
• Продакт-менеджер: является владельцем линейки продуктов/кода, но видит
объем продаж только своего продукта.
• Директор магазина: знает оборот продаж и ассортимент одного магазина (то
есть видит только свой магазин).
• Администратор: должен иметь доступ ко всем данным.
• Аналитик данных: должен иметь доступ ко всем данным, исключая персо-
нальную информацию.
• Менеджеры по удержанию клиентов: должны понимать закономерности
клиентского трафика.
• Специалисты по data science: необходим доступ к необработанным и об-
работанным данным для создания рекомендаций и прогнозов.
После определения персонажей следует составить для них бизнес-сценарии.
Приведем несколько примеров.
• Тренды покупательской активности: анализ количества клиентов, увели-
чивающих или сокращающих свои траты со временем. Характеризуйте этих
клиентов на основании структуры их расходов.
• Категории роста среди потребителей с увеличивающимися расходами: опре-
делите, в каких категориях продуктов или сервисов наблюдаются более высо-
кие темпы роста среди клиентов, увеличивающих свои расходы со временем.
• Категории замедления среди потребителей со снижающимися расходами:
определите, в каких категориях наблюдается снижение вовлеченности кли-
ентов, уменьшающих свои расходы со временем.
• Влияние демографии на расходы: исследуйте, какие демографические фак-
торы (размер домохозяйства, наличие детей, уровень доходов и т. д.) влияют
на характер трат клиентов. Кроме того, оцените, какие демографические
факторы влияют на вовлеченность по конкретным категориям продуктов
или сервисов.
• Эффективность директ-маркетинга: выясните, существуют ли убедительные
доводы в пользу того, что кампании директ-маркетинга помогают повысить
вовлеченность клиента.
• Влияние директ-маркетинга на другие категории: оцените, оказывает ли
директ-маркетинг в одной категории положительный эффект на вовлечен-
ность клиентов в других категориях.
После выяснения деталей бизнес-сценариев следующим важным этапом соз-
дания архитектуры данных станет понимание закономерностей обращений
к данным и политик хранения. Эти параметры можно проанализировать с по-
мощью следующих вопросов.
Проектирование архитектур Big Data 473
• Как часто ключевые пользователи и персонажи запрашивают свои отчеты?
• Каковы их ожидания относительно актуальности данных?
• Каковы их ожидания относительно детализации данных?
• К какой части данных они чаще всего обращаются для анализа?
• Как долго данные должны храниться для аналитических целей?
• В какой момент данные будут считаться утратившими актуальность и могут
быть исключены из среды озера данных?
При работе с данными всегда приходится учитывать множество нюансов.
В каждой стране и каждом регионе действуют свои локальные нормативные
требования, которые должен понимать архитектор данных:
• Какие требования комплаенса предъявляет бизнес?
• Распространяются ли на вас требования локальности данных, конфиденци-
альности или скрытия данных?
• Кому разрешено видеть записи и атрибуты в датасете?
• Как будет обеспечено удаление записей по требованию?
• Где будут храниться данные (локальное/региональное/глобальное храни-
лище)?
Вы, как архитектор данных, также должны учитывать фактор окупаемости и его
влияние на бизнес-решения. Для этого стоит ответить на следующие вопросы.
• Какие основные бизнес-процессы и решения поддерживают ваши озера
данных?
• Какой уровень детализации необходим для этих решений?
• Как задержка данных влияет на бизнес-решения?
• Как вы собираетесь оценивать успех?
• Какую окупаемость вы планируете за затраченное время и материалы?
В конечном счете вам требуется архитектура данных, которая допускала бы
гибкий выбор технологических решений — например, за счет использования
облачных управляемых сервисов и технологий с открытым исходным кодом.
Big Data-решения должны строиться так, чтобы применять параллелизм
для достижения высокого уровня производительности и масштабирования.
Следует позаботиться о том, чтобы любые компоненты пайплайна Big Data
могли независимо масштабироваться по возрастанию и убыванию для воз-
можности их корректировки в соответствии с разными рабочими нагрузками
бизнеса.
Чтобы задействовать весь потенциал выбранного вами решения, следует обес-
печить его совместимость с существующими приложениями, чтобы компоненты
архитектуры больших данных также использовались для задач МО и корпоратив-
ных ВI-решений (business intelligence). Это позволит вам создавать интегриро-
ванные решения, совмещающие разные рабочие нагрузки данных. В следующем
разделе рассматриваются некоторые паттерны архитектур Big Data.
474 Глава 12. Инженерия данных для архитектур решений
Архитектура озера данных (data lake)
Озеро данных служит центральным репозиторием, который аккумулирует
структурированные и неструктурированные данные разнообразных типов, ис-
пользуемых в корпорации. Концепция озера данных появилась как решение
для переноса всех корпоративных данных в экономичную систему хранения
(например, Amazon S3). К данным в озере можно обращаться через обобщенные
API и открытые форматы файлов, включая Apache Parquet и ORC (Optimized
Row Columnar). Этот метод сохраняет данные в исходной форме, используя
открытые форматы файлов для приложений прямой аналитики и МО.
Озеро данных становится популярным способом хранения и анализа больших
объемов данных в централизованном репозитории. Данные могут сохраняться
«как есть» в текущем формате, без необходимости преобразовывать их к заранее
определенной схеме, что повышает скорость поглощения данных. Как показано
на рис. 12.6, озеро данных является единым источником достоверных данных
в организации.
DQ (data quality)-
запросы
BI (Бизнес-аналитика)
Интерактивность В реальном времени
Каталог
Рис. 12.6. Объектное хранилище для озера данных
Проектирование архитектур Big Data 475
Основные преимущества озер данных:
• поглощение данных из различных источников: озера данных позволяют хра-
нить и анализировать данные из разнообразных источников — реляционных
и нереляционных баз данных и потоков — в одном централизованном при-
емнике, который становится единым источником достоверных данных (source
of truth). Это ответ на такие вопросы, как «Почему данные распределены во
многих местах?» и «Где находится единый источник достоверных данных?»;
• сбор и эффективное хранение данных: озеро данных может поглотить любую
структуру данных, включая полуструктурированные и неструктурированные
данные, без обязательной схемы. Это ответ на вопрос «Как быстро поглотить
данные из различных источников в разных форматах и эффективно сохра-
нить их в масштабе?»;
• восходящее масштабирование по объему генерируемых данных: озера
данных позволяют разделить уровни хранения и вычисления, чтобы каждый
компонент мог масштабироваться по отдельности. Это ответ на вопрос «Как
организовать масштабирование по объему генерируемых данных?»;
• применение аналитики к данным из разных источников: в озере данных мож-
но определить схему для чтения и создать централизованный каталог данных
для информации, полученной из разных источников, что дает возможность
быстро проводить ситуативный анализ. Это ответ на вопрос «Смогу ли я при-
менять разные методы аналитики и обработки к одним и тем же данным?»
Для озера данных предпочтительно иметь решение для неограниченного масшта-
бируемого хранилища данных. У разделения обработки и хранения есть много
преимуществ, включая возможность обработки и анализа одних данных с приме-
нением разных инструментов. Хотя это может потребовать лишнего шага загрузки
данных в нужную программу, Amazon S3 в качестве центрального хранилища
данных предоставляет еще больше преимуществ, чем традиционные варианты
хранения. На рис. 12.7 показано озеро данных, использующее сервисы AWS.
На диаграмме изображено озеро данных, работающее Amazon S3. Данные по-
глощаются централизованным хранилищем из разных ресурсов (например,
реляционных баз данных и мастер-файлов данных). На уровне необработан-
ных данных все данные хранятся в исходном формате. Затем они проходят
каталогизацию и преобразование с использованием сервиса AWS Glue. AWS
Glue — бессерверное решение для каталогизации данных и процессов ETL, по-
строенное на базе Spark в облачной платформе AWS. Бот AWS Glue упрощает
процесс каталогизации хранилищ данных. Он автоматически сканирует источ-
ники данных, идентифицирует форматы данных и определяет схемы, создавая
и заполняя каталог данных информацией метаданных. Бот классифицирует
данные, чтобы понять их формат и структуру, и создает определения таблиц
в каталоге данных, что упрощает построение запросов для аналитики. После
преобразования данные сохраняются на уровне обработанных данных озера,
что делает возможным их дальнейшее потребление.
klb Глава 12. Инженерия данных для архитектур решений
3 Облако AWS
Рис. 12.7. Архитектура озера данных на платформе AWS
Инженеры данных могут выполнять ситуативные запросы с использованием
Amazon Athena — бессерверного сервиса запросов, построенного на базе управ-
ляемых экземпляров Presto, — и использовать SQL для прямых запросов данных
из Amazon S3. Бизнес-аналитики могут использовать Amazon QuickSight, Tableau
или Power BI для построения визуализаций для бизнес-пользователей или из-
бирательно загружать данные в Amazon Redshift для создания витрины (mart)
данных. Наконец, аналитики данных могут потреблять их с использованием
Amazon Sage Maker для целей МО.
Ни один инструмент не является универсальным. Для каждой задачи необходим
свой подходящий инструмент, а озера данных позволяют строить архитектуры
больших данных с широкими возможностями настройки, которые можно адап-
тировать для конкретных целей.
Тем не менее со временем пришло осознание, что у озер данных есть свои огра-
ничения. Так как озера используют дешевые хранилища, компании стараются
хранить там как можно больше данных, пользуясь гибкостью открытого, пря-
мого доступа к файлам. Из-за проблем с качеством данных и детализированным
управлением доступом озера быстро стали превращаться в «болота». Чтобы
решить проблемы с производительностью и качеством озер данных, организа-
ции обрабатывают небольшие подмножества данных из озера в нижележащем
едином хранилище данных, чтобы использовать их в BI-приложениях бизнес-
аналитики для принятия ключевых решений.
Двухсистемная архитектура с озером данных (data lake) и хранилищем данных
(data warehouse) требует непрерывной инженерии данных для их поддержания
Проектирование архитектур Big Data 477
и обработки между двумя системами. На каждом этапе обработки появляется
риск сбоев, которые могут повлиять на качество данных. Кроме того, согла-
сование данных между озером и хранилищем может быть и непростой, и за-
тратной операцией. Пользователи сталкиваются с необходимостью платить за
хранение дважды — один раз за данные, хранящиеся в озере, а потом за данные,
реплицируемые в хранилище. Эти затраты прибавляются к текущим затратам
на непрерывную обработку данных.
Для решения проблем двухсистемной архитектуры появилась новая разновид-
ность архитектуры, называемая озером-хранилищем данных (data lakehouse).
В следующем разделе эта архитектура рассматривается более подробно.
Архитектура озера-хранилища данных
(data lakehouse)
Архитектура озера-хранилища сформировалась как решение, заполняющее
пробел между традиционными озерами данных и хранилищами данных. Оно
сочетает сильные стороны обеих архитектур. Основной задачей при проектиро-
вании этой архитектуры был контроль над огромной емкостью озер данных для
поглощения и хранением огромных объемов данных в открытых форматах, что
необходимо для аналитики. При этом она также стремится обеспечить простоту
SQL-запросов и надежность, присущую хранилищам данных. Назовем ключевые
характеристики архитектуры озера-хранилища данных.
• Хранение данных в открытых форматах: это упрощает взаимодействия
и увеличивает гибкость при обработке данных и аналитике.
• Разделение хранения и вычислений: это делает возможным независимое
масштабирование и оптимизацию каждой подсистемы, что приводит к по-
вышению эффективности и производительности.
• Транзакционные гарантии: обеспечивая целостность данных, архитектура
озера-хранилища данных гарантирует (по аналогии с гарантиями традици-
онных систем баз данных) поддержку надежного конкурентного доступа
и модификаций.
• Поддержка разнообразных потребностей использования данных: архитек-
тура включает разные методы аналитики и обработки данных, от пакетных
до потоковых в реальном времени.
• Безопасность и рациональное управление: архитектура гарантирует кон-
троль над доступом к данным и соответствие нормативным требованиям
к конфиденциальности данных.
• Унифицированная платформа: архитектура предоставляет унифициро-
ванную платформу для различных операций с данными, от процессов ETL
и МО до бизнес-аналитики и построения отчетов, снимая необходимость
в использовании разных систем.
478 Глава 12. Инженерия данных для архитектур решений
• Улучшенная производительность запросов: за счет применения таких мето-
дов, как индексирование, кэширование и группировка данных, повышается
производительность запросов, вследствие чего архитектура лучше подходит
для сложных аналитических рабочих нагрузок.
• Экономичная масштабируемость: это позволяет выдержать баланс между
потребностью в производительности и бюджетными ограничениями, особенно
важный для расширения томов данных.
• Гибкое управление данными: архитектура поддерживает гибкие практики
управления данными, возможность адаптироваться к эволюционирующим
схемам данных и структурам, вследствие чего она идеально подходит для
адаптивных и развивающихся бизнес-сред.
Архитектура озера-хранилища стала значительным достижением в управлении
данными. Она предоставляет всесторонний, масштабируемый и эффективный
подход к работе с обширными, разнообразными датасетами, при этом обеспечивая
целостность, безопасность данных и удобный доступ к ним.
На рис. 12.8 представлен пример архитектуры озера-хранилища, использу-
ющей Redshift Spectrum для совместного доступа к данным. Amazon Redshift
Spectrum предоставляет возможность запрашивать данные из озера без пере-
мещения их в хранилище. Представим, что вы уже используете Amazon Redshift
для создания хранилищ данных. В таком случае вам не нужно выгружать
все данные в кластер Amazon Redshift и вы можете использовать Spectrum
для запроса данных непосредственно из озера Amazon S3 и объединения их
с данными из хранилища.
Данные поглощаются
из локального EDW
в Amazon S3 через S3 API
Локальные
базы данных
Каталог данных
AWSGIue
используется для
хранения метаданных
Владение данными
Данные кредитных историй
и займов поддерживаются
независимо каждым отделом
Совместное использование данных
Если сотруднику отдела скоринга
понадобится доступ к данным по займам,
вы можете предоставить ему схему
данных в режиме read-only
Доступ к данным
Авторизованные пользователи получают
read-only доступ к данным в S3 через
Redshift Spectrum
Рис. 12.8. Архитектура озера-хранилища (lakehouse) на облачной платформе
AWS с использованием Redshift Spectrum
Проектирование архитектур Big Data 479
Данные поглощаются из локального корпоративного хранилища данных (EDW,
Enterprise Data Warehouse) в S3 с использованием S3 API, как показано на
диаграмме выше. AWS Glue сохраняет метаданные, а также данные кредитных
историй и займов по отдельности.
Сотрудники отдела кредитования имеют доступ только для чтения (read-only)
к данным о выданных займах. Сотрудники отдела скоринга (оценка кредито-
способности) имеют доступ только для чтения (read-only) к данным кредитных
историй. Если аналитику по кредитным рискам потребуются данные о займах,
ему предоставляется read-only схема данных по займам с ограниченным на-
бором полей.
Архитектура озера-хранилища имеет свои преимущества; однако у организаций
со сложной структурой приложений, зависящей от географически разделенных
бизнес-подразделений, требования более высокие. Эти подразделения уже ор-
ганизовали озера и хранилища данных в качестве аналитических источников.
Каждое подразделение может объединять озера данных нескольких внутренних
приложений для поддержки своих бизнес-целей. Создать централизованные
корпоративные озера или озера-хранилища непросто, поскольку изменения
обычно распространяются медленно, и выполнить все требования разных биз-
нес-подразделений достаточно затруднительно. Для решения этой проблемы
понадобятся предметно-ориентированные концепции децентрализованного
владения данными и архитектуры. На помощь приходит архитектура сетки
данных (data mesh), которая будет рассмотрена в следующем разделе.
Архитектура сетки данных (data mesh)
Главное отличие сетки данных от озера-хранилища заключается в том, что данные
в ней намеренно остаются распределенными, не так, как в озере, где несколько
предметных областей объединяются под централизованным управлением. Сетка
данных предоставляет схему, которая позволяет крупной организации связать
несколько внутренних озер / озер-хранилищ и упростить совместное использо-
вание данных с партнерами, научной средой и даже конкурентами.
Сетка данных представляет собой значительный сдвиг парадигмы как в ар-
хитектурных, так и в организационных подходах к управлению обширными
аналитическими датасетами. Архитектура сетки данных основана на четырех
фундаментальных принципах.
• Децентрализация владения и архитектуры на основе предметной области:
этот принцип выводит на первый план децентрализацию владения данными
и архитектурных решений и передачу их конкретным областям бизнеса.
Отдельные бизнес-области принимают ответственность за свои данные, что
способствует созданию более эффективных и специализированных решений.
• Обращение с данными как с продуктом: это означает, что при обслужива-
нии, улучшении и представлении данных учитываются интересы конечного
480 Глава 12. Инженерия данных для архитектур решений
пользователя. Представление о данных как об обычном ресурсе преобразуется
в представление о ценном активе, который приносит практическую пользу
и решает задачи конечного пользователя.
• Федеративное управление данными с централизованным контролем
аудита: этот принцип помогает выдержать баланс между децентрализо-
ванным управлением данными и потребностью в общем контроле. Он
позволяет конкретным бизнес-областям распоряжаться своими данными
при сохранении централизованного контроля в целях аудита и обеспече-
ния комплаенса.
• Общий доступ: этот принцип, обеспечивающий доступность данных и воз-
можность их использования в границах организации, направлен на создание
общего фреймворка, позволяющего легко и эффективно потреблять данные.
Архитектура сетки данных поощряет адаптивность, управляемую данными,
и поддерживает контроль данных с привязкой к бизнес-областям за счет по-
литики облегченной централизации. Сетка данных обеспечивает грамотное
владение данными благодаря изоляции ресурсов данных с четким разделением
ответственности.
Основная концепция сетки данных — представление доменов данных как узлов
в озере данных. Производитель данных заносит один или несколько продуктов
данных в центральный каталог под учетной записью сетки данных. При этом
совместное использование продуктов данных подчиняется федеративному
контролю, что способствует прозрачности метаданных и аудируемости. По-
требитель данных проводит поиск в каталоге и получает доступ к продукту
данных. Совместный доступ к ресурсу организуется через паттерн сетки данных.
На рис. 12.9 изображена архитектура сетки данных в облаке AWS.
Учетная запись озера данных
• Регистрация место-
положения данных
Учетная запись федеративного контроля
Учетная запись потребителя
1
Необработанные Доверенные Очищенные
Каталог
данных
Роль IAM
@ Создание локальной базы данных
ф Создание ссылки на ресурс в таблице
• Предоставление роли бота Glue разрешений для изменения/
обновления БД/табл и ц через LF
• Запуск бота для существующей таблицы каталога (таблица ссылок
на ресурсы)
Роль IAM
Amazon AWS Amazon
Athena Glue Redshift
Каталог данных
Каталог Создание БД
. _Д_ -Н- - _ _ _ _ и 'аблицы
т"’^цоГ;-------------
таблицы ।
Изменение метаданных
из озера данных обеспечивает
согласование каталога
с изменениями схемы
и/или разделов
। ф Создание БД/ссылки на ресурс
i /х\ Предоставление роли LAM (потребителя)
I ™ разрешения SELECT через LF
Потребитель отправляет запрос
L _ к учетной записи производителя _
Рис. 12.9. Архитектура сетки данных на облачной платформе AWS
Проектирование архитектур Big Data 481
Основные компоненты сетки данных на приведенной диаграмме:
• центральная учетная запись AWS, в которой регистрируются продукты
данных, включая базы данных, таблицы, столбцы и строки;
• теги управления доступом и политики доступа к тегам находятся под цен-
трализованным управлением;
• хранение разрешений данных, реализующих совместное использование
с потребителем. Разрешения могут быть как прямыми, так и основанными
на тегах;
• применение политик безопасности и управления к учетным записям произ-
водителя и потребителя, а также опубликованным ими продуктам данных.
Архитектура сетки данных позволяет ускорить независимую поставку озер-хра-
нилищ для разных бизнес-областей. Сетка данных повышает безопасность дан-
ных и комплаенс в предметных областях и делает возможным самостоятельное
создание, обнаружение и подписку на продукты данных, позволяя потребителям
беспрепятственно получать доступ к ним.
В настоящее время растет потребность в быстром получении аналитических
данных и оперативном реагировании на потребности клиентов, вследствие чего
аналитика потоковых данных становится важной для любого бизнеса. В сле-
дующем разделе архитектура аналитики потоковых данных рассматривается
более подробно.
Архитектура потоковых данных
Потоковые данные — стремительно расширяющийся в последнее время сег-
мент. Они требуют поглощения и быстрой обработки в реальном времени, при
этом они поступают из разнообразных источников. Такими источниками могут
быть видео и аудио, журналы приложений, данные посещений сайтов и теле-
метрии 1оТ. Цель во всех случаях одна — быстро получить аналитические выводы
для бизнеса. Типичные сценарии использования потоковых данных строятся
по одной схеме.
1. Генерирование данных: источники постоянно производят данные.
2. Поглощение: данные проходят через стадию поглощения на уровень хране-
ния потоковых данных.
3. Хранение потоковых данных: на этом уровне входные данные надежно со-
храняются и становятся доступными для обработки в реальном времени.
4. Потоковая обработка: на этой стадии происходит обработка данных, на-
ходящихся на уровне хранения. Это могут быть фильтрация, агрегирование
или анализ передаваемых данных.
5. Вывод данных: обработанные данные передаются в указанное место назна-
чения, которым может быть база данных, озеро данных или другое решение,
для дальнейшего использования или долгосрочного хранения.
482 Глава 12. Инженерия данных для архитектур решений
Такая схема гарантирует, что данные будут не только сгенерированы, но и свое-
временно обработаны, что способствует более быстрому принятию решений
и получению бизнес-инсайтов.
Архитектура потоковых данных отличается от других тем, что необходимо об-
рабатывать непрерывный поток данных с очень высокой скоростью. Часто эти
данные являются полуструктурированными и требуют сложной обработки,
чтобы из них можно было извлечь полезную информацию. При проектировании
архитектур потоковых данных необходимо обеспечить быстрое масштабирова-
ние хранилища данных. Очень важно также идентифицировать закономерности
в данных в реальном времени (особенно для временных рядов).
При проектировании следует уделять внимание производителю, генерирующему
поток данных (например, датчикам 1оТ), тому, как планируется хранить и об-
рабатывать данные с использованием средств обработки в реальном времени,
и, наконец, организации запросов к данным в реальном времени. На рис. 12.10
изображен пайплайн аналитики потоковых данных, использующий управляемый
сервис на платформе AWS.
Устройство 1оТ
(на ветроэлектро-
станции)
Рис. 12.10. Аналитика потоковых данных для данных 1оТ
Amazon Kinesis
Data Analytics
for SQL
Amazon Kinesis
Data Analytics
for Java Flink
Amazon Simple
Storage Service
(Amazon S3)
Amazon
OpenSearch
На диаграмме показано, как поглощается поток данных от ветроэлектростанции;
это нужно для анализа работоспособности и скорости ветряных двигателей. Важ-
но управлять устройствами в реальном времени, чтобы избежать дорогостоящего
ремонта в случае, если скорость ветра превышает предельное значение двигателя.
Данные от ветряного двигателя поглощаются в Kinesis Data Streams при помощи
AWS IoT Greengrass. Сервис Kinesis Data Streams позволяет хранить потоковые
данные до одного года и предоставляет возможность воспроизведения. Данные
могут доставляться нескольким ресурсам, откуда их можно отправлять при
Проектирование архитектур Big Data 483
помощи Lambda и сохранять в Amazon S3 для дальнейшей аналитики с исполь-
зованием Amazon Kinesis Firehose.
Запросы к потоковым данным в реальном времени можно отправлять с исполь-
зованием простых запросов SQL при помощи Kinesis Data Analytics for SQL,
автоматизировать пайплайн данных для преобразования потоковых данных
в реальном времени при помощи Kinesis Data Analytics for Java Flink и сохранять
обработанные данные в Amazon OpenSearch для получения аналитики. Также
можно добавить Kibana в OpenSearch для визуализации данных ветряного
двигателя в реальном времени.
Описанное решение не зависит от данных и легко настраивается, что позволяет
клиентам быстро изменять готовую конфигурацию по умолчанию и писать код,
включающий специализированную бизнес-логику.
Выбор подходящей архитектуры Big Data
Выбор между архитектурой озера данных, озера-хранилища и сетки данных
зависит от конкретных бизнес-требований, стратегии данных и технических
возможностей. Каждая архитектура обладает уникальными преимуществами
и лучше всего работает в определенных сценариях управления данными и ана-
литики. Чтобы вам было проще сделать правильный выбор, ниже показаны
преимущества, основные факторы и идеальные сценарии использования для
каждого типа архитектуры.
• Озеро данных предназначено прежде всего для хранения больших объемов
необработанных данных в исходном формате.
Преимущества: обеспечивает высокую масштабируемость и гибкость при
работе с разными типами данных. Экономичное решение для хранения
больших объемов данных, может использоваться как центральный репо-
зиторий для всех данных организации.
Недостатки: без должного контроля озера данных могут стать неуправляе-
мыми (превратиться в «болота данных»). Обеспечение качества данных
и доступности требует тщательного управления.
Сценарии использования: хорошо подходит для аналитики Big Data, МО
и сценариев, требующих хранения и анализа больших объемов разнород-
ных данных при низких затратах — включая структурированные, полу-
структурированные и неструктурированные данные — без обязательного
наличия заранее определенной схемы в точке входа данных.
• Озеро-хранилище данных сочетает элементы озера данных и хранилища
данных.
Преимущества: экономичное масштабирование озер данных в сочетании
с мощной поддержкой схем и оптимизацией производительности, прису-
щих хранилищам данных. Предоставляет унифицированную платформу
для всех типов обработки данных и аналитики, сокращая необходимость
484 Глава 12. Инженерия данных для архитектур решений
в обособленных базах данных. Также поддерживает транзакции ACID
и схемы, повышая надежность и качество данных.
Недостатки: реализация этой архитектуры может оказаться сложной, так
как она требует интеграции разных компонентов и обеспечения согласо-
ванности и надежности между разными рабочими нагрузками.
Сценарии использования: лучше всего подходит для организаций, тре-
бующих обработки больших данных и традиционной бизнес-аналитики
на одной платформе. Идеальна для сценариев, требующих аналитики
в реальном времени и отчетов на больших и разнородных датасетах.
• Сетка данных: упор на децентрализацию архитектуры данных и владение ими.
Данные рассматриваются как продукт, а команды разных бизнес-областей
владеют своими данными и предоставляют их в виде продуктов остальным
подразделениям организации.
Преимущества: более динамичное и гибкое управление данными и ана-
литический подход. Также способствует демократизации данных, что
позволяет быстрее принимать решения и применять инновации в биз-
нес-областях.
Недостатки: требует изменения подхода к управлению и совместному
использованию данных. Необходимы продуманное управление и стан-
дартизация между бизнес-областями, чтобы обеспечить совместимость
и качество данных.
Сценарии использования: подходит для больших организаций с несколь-
кими независимыми командами или отделами, где разные бизнес-области
производят и потребляют данные.
Ключевые факторы для принятия решения:
• организационная структура: оцените, является ваша организация центра-
лизованной или децентрализованной. Сетка данных лучше подходит для
второго типа;
• объем и разнообразие данных: озера данных идеально подходят для больших
разнообразных наборов данных, тогда как озера-хранилища предоставляют
более структурированную среду для таких данных;
• аналитические потребности: озеро-хранилище может быть оптимальным
вариантом, если вам нужна аналитика в реальном времени в сочетании с об-
работкой больших данных;
• управление и комплаенс: оцените потребности в управлении данными, ка-
честве и нормативном соответствии. Архитектура озера-хранилища обычно
обеспечивает более мощные механизмы управления;
• техническая квалификация: реализация и управление сеткой данных или озе-
ром-хранилищем требует специфических технических навыков или ресурсов.
В конечном счете выбор определяется соответствием архитектуры бизнес-целям,
техническим возможностям и стратегии данных. У каждой архитектуры есть свои
сильные стороны, и лучшим вариантом может даже оказаться гибридный подход.
Лучшие практики архитектуры Big Data 485
Лучшие практики архитектуры Big Data
В предыдущих разделах были рассмотрены технологии и архитектурные пат-
терны больших данных. Для изучения лучших практик давайте рассмотрим
рис. 12.11, где в качестве референса показана диаграмма архитектуры озера
данных с разными уровнями.
Рис. 12.11. Архитектура озера данных как референс
На диаграмме изображен сквозной пайплайн данных в архитектуре озера дан-
ных с использованием облачной платформы AWS. Он включает следующие
компоненты.
• AWS Direct Connect настраивает скоростное сетевое подключение между
локальным центром данных и AWS для миграции данных. Если вы работаете
с большими объемами архивных данных, лучше воспользоваться семейством
AWS Snow для выведения их в офлайн.
• Уровень поглощения данных с разными компонентами поглощает по-
токовые данные при помощи Amazon Kinesis, реляционные данные при
помощи AWS DMS (Data Migration Service), безопасно передает файлы
при помощи AWS Transfer for SFTP (Secure Shell File Transfer Protocol),
обновляет файлы данных между облачными и локальными системами при
помощи AWS DataSync.
• Централизованное хранилище для всех данных с использованием Amazon S3
содержит несколько уровней для хранения необработанных, обработанных
и архивных данных.
486 Глава 12. Инженерия данных для архитектур решений
• Amazon Redshift — облачно-ориентированное решение хранилищ данных
с Redshift Spectrum для поддержки архитектуры озера-хранилища.
• Функциональность ситуативных (ad hoc) запросов с использованием Amazon
Athena.
• Быстрый пайплайн ETL на базе Spark с использованием AWS Glue.
• Amazon EMR повторно использует существующие скрипты Hadoop и другие
фреймворки Apache Hadoop.
• Amazon Lake Formation для подробной каталогизации данных и детализи-
рованного управления доступом на уровне озер данных.
• Расширение ИИ/MO с Amazon SageMaker.
Среди других компонентов можно упомянуть Amazon KMS (Key Management
Service) для шифрования данных, Amazon I AM (Identity and Access Management)
для управления доступом, Amazon Macie для выявления персональной информа-
ции с целью соблюдения таких нормативов, как PCI DSS (Payment Card Industry
Data Security Standard), CloudWatch для мониторинга операций и CloudTrail
для аудита операций в озере данных.
Для проверки архитектуры больших данных используются следующие критерии.
• Безопасность:
классификация данных и определение соответствующих политик защиты
данных с использованием управления доступом на базе ресурсов;
реализация надежной основы для идентификации с использованием
пользовательских разрешений и системы единого входа (SSO);
включение трассировки среды и данных для целей аудита;
обеспечение безопасности на всех уровнях, защита данных при передаче
и при хранении с применением SSL и шифрованием на всех уровнях;
защита данных от посторонних — например, блокировка доступа для за-
писи к базам данных в продакшен-среде.
• Надежность:
поддержание гигиены данных с использованием автоматического про-
филирования на базе каталогизации данных;
кправление жизненным циклом активов данных, переходами и сроком
жизни с использованием распределения данных между хранилищем
и озером данных;
сохранение информации о происхождении данных путем поддержания
истории перемещения данных по каталогу;
проектирование устойчивости в пайплайнах аналитики и отслеживание
системных SLA с автоматизированным восстановлением сбоев заданий
ETL.
Итоги 487
• Производительность:
профилирование данных для повышения производительности при про-
верке данных для формирования уровня очистки;
непрерывная оптимизация хранения данных — например, сжатие данных
в формате Parquet, секционирование данных, оптимизация размеров
файлов и т. д.
• Оптимизация затрат:
принятие модели потребления и определение типа требуемых запросов —
ad hoc или быстрые;
удаление неиспользуемых данные; определение правил хранения и уда-
ление или архивирование данных с истекшим сроком хранения;
отделение вычислений от хранения в решениях на базе озер данных;
реализация эффективной миграции за счет применения разных стратегий
миграции для разных источников и объемов данных;
использование управляемых сервисов и сервисов уровня приложения
для сокращения затрат владения.
• Операционное совершенство:
реализация стратегии «операции как код» при помощи таких инструмен-
тов, как CloudFormation, Terraform и Ansible;
автоматизация операционных процессов, включая создание уровня орке-
страции на базе Step Functions иди Apache Airflow;
раннее предсказание сбоев за счет непрерывного мониторинга и автома-
тизации восстановления после отказов ETL-задач;
контроль состояния рабочей нагрузки.
Используйте этот список для проверки архитектуры Big Data. Инженерия
данных — обширная тема, и подробное рассмотрение каждого раздела требует
не одной книги.
В этой главе мы рассмотрели ключевые компоненты инженерии данных в рамках
распространенных архитектурных паттернов. Это позволит вам начать работу
и глубже изучить данную тему.
Итоги
Вы узнали об архитектуре Big Data и компонентах пайплайна Big Data, о по-
глощении данных и технологиях сбора пакетных и потоковых данных для
дальнейшей обработки. Поскольку облачные технологии занимают сейчас цен-
тральное место в хранении больших объемов данных, мы рассказали о сервисах,
используемых для поглощения данных в облачной экосистеме AWS.
488 Глава 12. Инженерия данных для архитектур решений
Хранение данных — один из ключевых аспектов обработки Big Data. Вы узнали
о типах хранилищ как структурированных, так и неструктурированных данных,
NoSQL и хранилищах данных, с перечислением возможных технологий для
каждого варианта. Также были рассмотрены облачные хранилища данных от
популярных облачных провайдеров.
После сбора и сохранения данные необходимо преобразовать, чтобы извлечь из
них полезную информацию и визуализировать выводы. Вы узнали о вариантах
архитектуры обработки данных и доступных технологиях — как с открытым ис-
ходным кодом, так и облачных, в зависимости от требований. Эти инструменты
обработки данных помогают получить аналитику и визуализировать данные
в зависимости от их характера и потребностей организации.
Вы узнали о паттернах архитектуры Big Data, включая озера данных, озера-хра-
нилища, сетки данных и архитектуру потоковых данных, и разобрались в том,
как выбрать архитектуру, подходящую для ваших целей. Наконец, вы систе-
матизировали лучшие практики построения архитектур Big Data, объединив
полученные знания в рамках референсной архитектуры.
На основе получаемых данных можно составлять прогнозы будущих событий;
такие прогнозы исключительно полезны для бизнеса. Для прогнозирования
будущих результатов на основании исторических данных часто применяется
машинное обучение (МО). Следующая глава посвящена МО и повышению
устойчивости архитектуры данных к будущим изменениям.
ГЛАВА 13
АРХИТЕКТУРА МАШИННОГО
ОБУЧЕНИЯ
В предыдущей главе вы узнали, как поглощать и обрабатывать большие дан-
ные и получать полезную аналитику для понимания бизнеса. В традиционном
варианте ведения бизнеса лицо, принимающее решения в организации, про-
сматривает данные прошедших периодов и на основании своего опыта строит
будущий курс компании. Но важно не только задать направление деятельности,
но и улучшать пользовательский опыт за счет предсказания и удовлетворения
потребностей клиентов или автоматизации повседневного принятия решений
(например, одобрения заявок на кредит).
Однако из-за колоссального объема доступных данных человеческому мозгу
становится все труднее обрабатывать их и делать прогнозы. На помощь приходят
искусственный интеллект (ИИ) и машинное обучение (МО). Искусственный
интеллект — более широкая концепция разумного выполнения машинами раз-
личных задач (например, Siri и Alexa), предполагающих понимание вопросов
и формулирование ответов, а МО — подмножество ИИ, относящееся к спо-
собности компьютеров учиться и принимать решения на основе данных. Эти
дисциплины помогают прогнозировать развитие событий на основе анализа
исторических данных. Сегодня многие корпорации инвестируют в МО — пре-
жде всего стремясь к ускорению, которое достигается благодаря генеративному
ИИ (GenAI). МО быстро становится технологией, которая помогает компаниям
выделяться на общем фоне — за счет создания новых продуктов, услуг и бизнес-
моделей, что позволяет им внедрять инновации и добиваться конкурентного
преимущества.
ИИ и МО отлично подходят для решения бизнес-задач, поскольку они предо-
ставляют бесчисленные сценарии использования в разных направлениях бизнеса
и высокую степень влияния, которое эти сценарии могут оказывать. Например,
МО позволяет сформировать новый уровень обслуживания клиентов в авто-
матизированных контактных центрах или помогает маркетинговым командам
добиться целей персонализации за счет запуска персонализированных марке-
тинговых кампаний.
490 Глава 13. Архитектура машинного обучения
В этой главе будут рассмотрены следующие темы.
• Что такое машинное обучение?
• Наука о данных (data science) и машинное обучение.
• Машинное обучение в облаке.
• Создание архитектуры машинного обучения.
• Принципы проектирования для архитектуры машинного обучения.
• MLOps.
• Глубокое обучение.
• Обработка естественного языка (NLP).
К концу главы вы будете понимать архитектуру и узнаете о разных моделях
и рабочих процессах МО. Вы поймете, как создается пайплайн модели МО по-
средством генерации признаков, обучения модели, инференса и оценки модели.
Что такое машинное обучение?
Машинное обучение улучшает взаимодействие с пользователем, повышает
эффективность бизнес-операций, ускоряет и повышает точность принятия
решений. С ростом вычислительных мощностей и объемов данных машинное
обучение переместилось с периферии, став основным отличительным качеством
бизнеса и организаций в различных отраслях. Сценарии использования МО —
персонализированные рекомендации продуктов и контента, автоматизация
контакт-центров, проверка виртуальной личности, интеллектуальная обработка
документов — применимы в большинстве отраслей. Также существуют сценарии,
специфичные для конкретных отраслей — например, клинические испытания
в фармакологии или контроль качества сборочных линий на производстве.
МО использует технологии для выявления новых тенденций и формирования
математических прогностических моделей на основе прошлых фактических
данных. МО может помочь с решением многих нетривиальных задач.
• Создание сложных правил: когда необходимо принимать решения, для ко-
торых невозможно прописать четкую логику в коде, например распознавание
человеческих эмоций в изображениях или речи.
• Анализ больших объемов данных: в случаях, когда объем информации слиш-
ком велик для эффективной обработки человеком. Например, хотя человек
может справиться с обнаружением спама, объем данных не позволяет быстро
решить эту задачу вручную.
• Динамическая адаптация: если информация, нужная для персонализации,
доступна только динамически, в режиме реального времени. Например,
индивидуальные рекомендаций товаров или персонализация веб-сайтов.
• Обработка потоковых данных: в ситуациях, требующих мгновенного анализа
больших данных для принятия решений, таких как обнаружение мошенни-
чества или обработка естественного языка (NLP).
Что такое машинное обучение? 491
Люди составляют прогнозы данных, базируясь на результатах анализа и своем
опыте. При помощи МО можно обучить компьютер предоставлять рекоменда-
ции на основе доступных данных и получать прогнозы на основе новых данных.
Вот несколько распространенных сценариев использования МО в различных
отраслях.
• Прогнозное обслуживание: предсказание возможных сбоев компонентов
на основании данных датчиков. Этот метод обычно применяется при оценке
остаточного срока эксплуатации (RUL, Remaining Useful Life) автопарков,
производственного оборудования и датчиков 1оТ. Его основными пре-
имуществами являются повышение времени полезной работы оборудова-
ния и значительная экономия средств. Это применение часто встречается
в автомобилестроении и производстве.
• Прогнозирование спроса: использование исторических данных для ускорен-
ного и более точного определения ключевых метрик спроса, способствующее
принятию более точных бизнес-решений о производстве, ценообразовании,
управлении запасами и приобретении/пополнении. Основные преимуще-
ства — удовлетворение покупательского спроса, минимизация затрат на
поддержание запасов за счет сокращения излишков, а также сокращение
отходов. Этот сценарий часто встречается в таких отраслях, как финансовые
услуги, производство, розничная торговля и товары широкого потребления.
• Обнаружение попыток мошенничества: автоматизация распознавания воз-
можных мошеннических действий и их пометка для дальнейшей проверки.
Основные преимущества — сокращение потерь от мошенничества и доверие
клиентов. Этот сценарий обычно реализуется в секторах финансовых услуг
и розничной торговли в интернете.
• Прогнозирование кредитных рисков: данный подход позволяет анализиро-
вать индивидуальные кредитные заявки для оценки вероятности погашения
кредита (так называемый кредитный дефолт). Преимущества связаны с вы-
явлением потенциальных предвзятостей в оценке и обеспечением соответ-
ствия нормативным требованиям. Этот сценарий характерен для отрасли
финансовых услуг и розничной торговли в интернете.
• Извлечение данных и анализ документов: распознавание текста в рукопис-
ных и цифровых документах, извлечение информации для классификации
и целей принятия решений. Данный сценарий широко распространен в таких
секторах, как здравоохранение, финансовые и юридические услуги, механика,
электротехника и образование.
• Персонализированные рекомендации: создание индивидуальных рекомен-
даций на основании исторических данных. Такой подход часто используется
в секторах розничной торговли и образования.
• Прогнозирование оттока: оценка вероятности того, что клиенты прекратят
пользоваться услугами. Часто используется в таких отраслях, как розничная
торговля, образование и у поставщиков SaaS (Software as a Service).
492 Глава 13. Архитектура машинного обучения
Основная концепция машинного обучения заключается в предоставлении
алгоритму обучающего датасета для последующего прогнозирования на новых
данных. Например, передача исторических данных о тенденциях фондового
рынка МО-модели позволяет прогнозировать рыночные колебания на период
от шести месяцев до года.
При разработке систем МО важно тщательно продумать синхронизацию данных
с кодом. Данные и алгоритм должны быть хорошо организованы и развиваться
под контролем для достижения общей цели — создания надежной и масштаби-
руемой системы МО.
Данные, используемые для обучения, тестирования и принятия решений
в механизме логического вывода (инференса) МО-системы, изменяются со
временем, так как поступают из разных мест. Код также должен изменяться
вместе с данными. Без систематизации неизбежны расхождения между кодом
и изменившимися данными. Несоответствие создаст проблемы, когда система
МО начнет использоваться для реальных задач. Оно также может затруднить
развертывание и привести к тому, что получаемые результаты будет трудно
понять, отследить или повторить.
Существуют разные типы МО; в следующем разделе мы рассмотрим их более
подробно.
Типы машинного обучения
МО помогает компьютерам получать новую информацию без программирования
всего, что для этого нужно. Фактически вы объясняете компьютеру, как учиться
на имеющемся опыте. Представьте, что вы обучаете собаку какому-нибудь трю-
ку: вы показываете, что нужно сделать, собака учится, а потом его выполняет!
С МО компьютеры могут учиться на данных, а затем использовать обучение для
принятия решений. Рассмотрим виды машинного обучения.
Обучение с учителем
При обучении с учителем (supervised learning) алгоритму предоставляется набор
обучающих примеров, в которых данные и целевые решения известны. После
этого он предсказывает целевое значение для новых наборов данных с теми же
атрибутами. При таком типе алгоритм обучается на датасете, в котором входные
данные связаны с правильным ответом (или целью). На этих примерах алгоритм
учится связывать входные данные с правильными результатами.
Такой тип обучения часто используется для задач, требующих классификации
объектов по категориям или предсказания чисел, как в задачах классификации
и регрессии. Например, он может применяться для разделения сообщений
электронной почты на спам и важные сообщения или прогнозирования цены
недвижимости на основании ее характеристик.
Что такое машинное обучение? 493
Обучение без учителя
При обучении без учителя (unsupervised learning) алгоритм получает огромный
объем данных и пытается выявить в них закономерности и отношения. После
этого он может делать выводы на основании наборов данных.
Обучение без учителя не требует участия человека — например, классификация
документов на основании их содержимого может происходить автоматически.
Таким образом решается проблема того, что правильный результат может быть
недоступен для обучающего набора, и алгоритм должен обнаружить закономер-
ности в данных посредством группировки.
При обучении без учителя модель обучается на неразмеченных данных. Алгоритм
самостоятельно выявляет закономерности, структуры и отношения в данных
без рекомендаций или примеров, которым нужно следовать. Такой тип обу-
чения часто применяется в задачах группировки, сокращения размерности
и оценки плотности. Новостным агентствам или юридическим фирмам часто
приходится иметь дело с большими объемами данных. Применяя обучение без
учителя, они могут автоматизировать классификацию документов, эффективно
управлять цифровыми репозиториями и совершенствовать процессы получения
информации — например, рекомендуя похожие статьи или дела читателям или
исследователям.
Обучение с частичным привлечением учителя
В варианте обучения с частичным привлечением учителя (semi-supervised
learning) объединяются элементы двух предыдущих типов. Здесь используется
небольшой объем размеченных данных и значительный объем неразмеченных
для повышения производительности модели. Такая модель особенно полезна,
когда получение размеченных данных либо обходится слишком дорого, либо
требует слишком длительного времени. Она часто используется в сценариях, где
размеченных данных мало, а неразмеченных, наоборот, очень много. Например,
обучение с частичным привлечением учителя может быть очень востребован-
ным в биомедицине. Разметка медицинских снимков требует большого времени
и ресурсов, вследствие чего такой тип обучения становится оптимальным вари-
антом. Модели могут изначально обучаться на небольшом наборе размеченных
снимков, после чего настраиваться на более обширном наборе неразмеченных,
что обеспечит максимальную пользу при минимальных затратах и ресурсах.
Обучение с подкреплением
Этот тип обучения (reinforcement learning) подразумевает обучение агентов
(компьютерных программ) для принятия последовательных решений в заданной
среде. Цель в том, чтобы агент научился выполнять наилучшие действия для
получения со временем максимально возможной совокупной награды. В ходе
Глава 13. Архитектура машинного обучения
обучения агенты выполняют действия, получают обратную связь (награды или
штрафы) и корректируют свои стратегии. Обучение с подкреплением использу-
ется в автономной робототехнике, играх (например, AlphaGo) и рекомендатель-
ных системах. Беспилотные автомобили применяют обучение с подкреплением,
перемещаясь по дороге и корректируя свои действия на основании окружающей
обстановки, что гарантирует принятие оптимальных решений в разнообразных
сценариях. Машина принимает серию решений (перестроение, изменение скоро-
сти и т. д.), получая положительное подкрепление для безопасных, эффективных
действий и отрицательное для нежелательных действий.
Самоконтролируемое обучение
Самоконтролируемое (self-supervised) обучение — это разновидность обучения
без учителя (unsupervised), когда алгоритм генерирует метки или цели на ос-
нове данных. Оно часто подразумевает такие операции, как прогнозирование
отсутствующих фрагментов данных. Самоконтролируемое обучение завоевало
популярность в NLP и распознавании образов для предварительного обучения
моделей на больших датасетах и дальнейшей настройкой под конкретные зада-
чи. В обработке изображений или распознавании образов самоконтролируемое
обучение может применяться для предсказания следующего кадра последова-
тельности, что упрощает создание моделей, понимающих принципы движения
и развития в визуальных данных. Предварительное обучение моделей подобным
образом с последующей настройкой для конкретных задач (например, обнару-
жения объектов) может принести впечатляющие результаты.
Обучение на множественных экземплярах
При обучении на множественных экземплярах (multi-instance learning) каждая
точка данных представляет собой «мешок» (bag), содержащий несколько экзем-
пляров (подчиненных точек данных). Цель заключается в том, чтобы обучаться
на мешках данных, имея доступ только к меткам уровня мешка. Такое обучение
находит применение в поиске новых лекарств, классификации изображений
и выборке изображений на основании контента.
Если взять для примера платформу электронной коммерции, обучение на
множественных экземплярах может предсказывать, приобретет ли клиент то-
вар в течение сессии (мешка), используя различные экземпляры, — такие, как
просмотры страниц, товары, по которым он кликал, и время, проведенное на
страницах. Метка сессии (то есть уровня мешка) может указывать, была ли со-
вершена покупка во время сессии; так создается надежная основа для прогнозов
и персонализированного показа контента.
Разнообразные парадигмы обучения, каждая из которых имеет свою специа-
лизацию и область применения, делают МО универсальной областью: модель
может адаптироваться к разным сценариям и задачам из разных отраслей и пред-
метных областей. Выбирая парадигму, подходящую для специфики и доступных
Data science и машинное обучение 495
данных конкретной задачи, практики МО могут создавать информированные
модели и способствовать осмысленному автоматизированному принятию
решений в приложениях. Важно выбрать тип обучения, который лучше всего
соответствует доступным данным и решаемой задаче, и обеспечить надежность
и практичность моделей.
В следующем разделе вы узнаете о том, как наука о данных (data science) не-
разрывно связана с МО.
Data science и машинное обучение
Вся суть МО заключается в работе с данными. Качество обучающих данных —
важнейшее условие успеха модели МО. Качественные данные позволяют соз-
давать более точные модели МО и получать верные прогнозы.
В данных часто присутствуют недостатки: пропущенные значения, шум, смеще-
ние, посторонние значения и т. д. Исследование данных позволит выявить эти
проблемы и предоставит необходимую информацию о качестве и чистоте данных,
интересных закономерностях в данных и возможных дальнейших действиях по-
сле начала моделирования. Data science включает сбор данных, их подготовку,
анализ, предварительную обработку и генерацию признаков (feature engineering).
Подготовка данных — первый шаг к построению модели МО. Он весьма про-
должителен и занимает до 80 % всего времени разработки модели. Подготовка
данных всегда считалась однообразной и трудозатратной задачей из-за того, что
необработанные данные по своей природе обычно «грязные» и не готовы для МО.
«Грязные» данные могут содержать пропуски или ошибки, а также посторонние
значения. Создание более точных и эффективных моделей МО часто требует
генерации признаков для преобразования входных данных.
Подготовка данных должна начинаться с понимания бизнес-задачи. Специалисты
data science часто стремятся поскорее начать обрабатывать данные, программи-
ровать и получать результаты. Однако без четкого понимания бизнес-задачи
любые результаты с большой вероятностью не подойдут для решения постав-
ленной задачи. Гораздо логичнее начать с простой пользовательской истории
и бизнес-целей, прежде чем углубляться в данные.
После полного понимания бизнес-задачи можно сузить категории задач МО
и определить, какая модель лучше подойдет для конкретной ситуации.
Подготовка данных часто включает ряд таких шагов, как очистка данных,
решение проблемы отсутствующих значений, нормализация/стандартизация
данных и их разметка. Эти шаги подробно рассматриваются далее в разделе
«Построение архитектуры машинного обучения». Большинство автономных
инструментов подготовки данных включает функциональность преобразования
данных, генерации признаков и визуализации. Преобразование данных может
496
Глава 13. Архитектура машинного обучения
включать такие операции, как конвертация валют (например, долларов в евро)
или переход на другие единицы измерения (скажем, с килограммов на фунты).
Генерация признаков включает создание новых столбцов данных (признаков)
из существующих, чтобы повысить информативность датасета для моделей
МО; например, извлечение дня недели или месяца из столбца данных может
помочь модели выявить закономерности, связанные со временем. Хотя такие
инструменты отлично справляются с подготовкой данных, им часто не хватает
встроенных возможностей для проверки модели — важнейшего этапа оценки
эффективности модели МО. Здесь нужен фреймворк, который предоставляет
всю эту функциональность в одном месте и при этом тесно интегрируется
с остальными частями пайплайна МО.
Как показано на рис. 13.1, предварительная обработка данных и создание модели
МО тесно связаны: подготовка данных существенно влияет на модель, а выбор
модели — на тип выполняемой подготовки данных. Поиск баланса — в высшей
степени итеративный процесс, который скорее является искусством (или про-
цессом многократных проб и ошибок).
Рис. 13.1. Рабочий процесс МО
Развертывание
конечной точки
модели в рабочей
среде
Как показано на диаграмме, рабочий процесс МО включает следующие этапы.
• Предварительная обработка: на этом этапе специалист по data science прово-
дит предварительную обработку данных и делит их на три набора: обучающий
(70 % данных), проверочный, или валидационный (10 % данных), и тестовый
(20 %). На первом модель обучается, накапливает информацию и учится да-
вать правильные предсказания. По завершении обучения модель применяется
к отдельному проверочному датасету для оценки ее эффективности и способ-
ностей к обобщению. После готовности модели ее можно протестировать на
тестовом наборе. Признаки являются независимыми атрибутами датасета,
которые могут влиять (или не влиять) на результат. Генерация подразумевает
Data science и машинное обучение 497
поиск правильных признаков, которые помогут обеспечить точность модели.
Метка — целевой результат, зависящий от выбора признаков. Сокращение
размерности может применяться для выбора правильных признаков, чтобы
отфильтровать и извлечь из данных самые содержательные.
• Обучение: на этом этапе для конкретного бизнес-сценария выбирается
подходящий алгоритм МО и данные. Это самый важный этап рабочего
процесса МО: на нем модель обучается на соответствующем датасете. Для
повышения точности модели необходимо экспериментировать с разными
гиперпараметрами и проводить выбор моделей. Гиперпараметры — на-
стройки конфигурации, используемые для управления процессом обучения
в алгоритмах МО.
• Оценка: после того как модель МО пройдет обучение, необходимо оценить
ее точность (accuracy) на известном датасете. Для оценки модели исполь-
зуется проверочный датасет, зарезервированный на этапе предварительной
обработки. По результатам оценки проводится дополнительная настройка
модели, если необходимо пересмотреть точность прогнозирования ввиду
исключений, определенных проверочными данными.
• Прогнозирование: также называется «логическим выводом» (inference). На
этом этапе модель применяется на практике и начинает делать прогнозы. Про-
гнозирование может происходить в реальном времени или в пакетном режиме.
Генеративный ИИ привел к сдвигу парадигмы в области МО и ИИ. В его осно-
ве лежат фундаментальные модели (ФМ) — такие, как GPT-4, — прошедшие
обучение на огромных датасетах в масштабе интернета и переопределившие
традиционные нормы разметки данных и настройки моделей. Эта революци-
онная технология позволяет организациям оптимизировать фундаментальные
модели, значительно сокращая привычные объемы ручных операций и времени
для подготовки данных.
Тем не менее важно понимать, что генеративный ИИ не панацея, поскольку эта
технология не проектировалась для решения всех проблем ИИ и МО. Кроме
того, разработка ФМ требует значительных ресурсов, включая вычислительную
мощность и доступ к обширным наборам данных. Как следствие, многие компа-
нии выбирают использование ФМ, предоставленных известными сторонними
поставщиками: OpenAI, Google, Meta и Anthropic, которые были первопроход-
цами в разработке этих моделей.
Но и это еще не все. Обучение специализированной модели остается привлека-
тельным вариантом — особенно там, где необходимы конкретные, специализи-
рованные решения. Хотя генеративный ИИ представляет новаторский подход
к решению задач, стратегическое решение о его принятии должно соответствовать
уникальным целям, ресурсам и ограничениям организации. Вы больше узнаете
о генеративном ИИ в главе 14 «Архитектура генеративного ИИ».
Как и в случае с входными данными, у модели МО часто возникают проблемы
переобучения (overfitting) или недостаточного обучения (underfitting), которые
498 Глава 13. Архитектура машинного обучения
необходимо учитывать для получения правильного результата. В следующем
разделе эта тема рассматривается более подробно.
Оценка моделей МО — переобучение
и недостаточное обучение
При переобучении модель нуждается в обобщении; иначе говоря, она должна
показывать хорошие результаты не только с данными, на которых она обучалась
(обучающий набор), но и на новых, не встречавшихся ранее данных (тестовый
или проверочный набор).
Если модель переобучена, она фактически запомнила обучающие данные и со-
хранила шум вместе со скрытой закономерностью, что приводит к низкой эф-
фективности на новых данных. Если модель демонстрирует высокие метрики
эффективности на обучающих данных, но существенно более низкие метрики
на тестовых данных, это является признаком переобучения.
Обычно переобучение указывает на то, что модель обладает излишней гиб-
костью в отношении обучающих данных, которая позволяет ей запоминать
данные, включая шум. Переобучение ведет к высокой дисперсии, когда не-
большие изменения обучающих данных приводят к значительным изменениям
результатов.
При недостаточном обучении модель не способна выявить важнейшие за-
кономерности в обучающем наборе. Как правило, недостаточное обучение
указывает на то, что модель слишком проста или в ней не хватает независимых
переменных. Недостаточно обученная модель должна быть более гибкой для
моделирования реальных закономерностей; недостаточное обучение указывает
на высокое смещение, обусловленное систематической нехваткой подгонки
модели в определенной области.
Диаграммы на рис. 13.2 наглядно демонстрируют различия между недостаточным
обучением и переобучением относительно хорошо обученной модели.
Рис. 13.2. Недостаточное обучение и переобучение модели МО
Переобучение
(высокая
дисперсия)
Data science и машинное обучение 499
Модель МО классифицирует две категории точек данных, обозначенных на
диаграммах кружками и крестиками. Модель МО пытается определить, купит
клиент заданный товар или нет. На иллюстрации изображены прогнозы трех
разных моделей МО. Модель с переобучением (справа) проходит при обучении
все «круглые» точки данных, но не может обобщить алгоритм для реальных
данных за пределами обучающего набора. С другой стороны, модель с недо-
статочным обучением (слева) пропускает несколько точек данных, ее точность
необходимо повысить. Хорошая модель (в середине) обычно предоставляет
четкие прогнозы точек данных. Создание хорошей модели МО сродни созданию
произведения искусства; возможно, вам удастся добиться такого результата при
помощи донастройки модели.
Популярные алгоритмы машинного обучения
Популярность алгоритма часто зависит от его применимости и эффективности
в разных сценариях использования, простоты понимания и реализации, а также
его способности к масштабированию и адаптации к разным типам данных. Рас-
смотрим некоторые популярные алгоритмы МО.
Линейная регрессия
Линейная регрессия пытается понять, в какой степени один фактор (скажем,
X) способен прогнозировать другой фактор (У), выявляя линейные отношения
между ними. Представьте, что вы пришли на рынок. Изучая цены на тыквы, вы
замечаете, что с ростом размера тыквы также растет ее цена. Линейная регрессия
словно пытается провести прямую линию между всеми ценами на тыквы так,
чтобы она проходила как можно ближе ко всем точкам.
Линейная регрессия играет важнейшую роль в секторе недвижимости. Например,
если компания хочет спрогнозировать цену продажи дома, она проверяет такие
признаки, как количество комнат в нем, его местоположение и дату постройки
(возраст). Если дома с большим количеством комнат в прошлом обычно про-
давались по более высокой цене, модель прогнозирует более высокую цену на
дома с большим количеством комнат. Принцип тот же, как для прогнозирования
цены тыквы в зависимости от размера.
Логистическая регрессия
Логистическая регрессия прогнозирует вероятность некоторого исхода на уровне
ответов «да» или «нет». Представьте, что вы пытаетесь предсказать, станет ли
книга бестселлером. Логистическая регрессия проверяет такие признаки, как
количество страниц, популярность автора и жанр, и предсказывает вероятность
(в интервале от 0 до 1) того, что книга станет бестселлером.
В здравоохранении логистическая регрессия может предсказать вероятность
некоторого заболевания у пациента на основании симптомов и результатов
500 Глава 13. Архитектура машинного обучения
анализов. Например, на основании таких факторов, как возраст, кровяное
давление и уровень холестерина, она может предсказать вероятность наличия
сердечных заболеваний. При высокой вероятности врачи могут провести до-
полнительные анализы, обеспечивая раннее снижение потенциальных рисков
для здоровья.
Деревья принятия решений
Деревья принятия решений помогают принимать серии решений путем ответа
на вопросы. Представим, что вам нужно выбрать подходящую одежду. Дерево
принятия решения может задать вопрос: «На улице идет дождь?» Если ответ
«да», оно может предложить дождевик. В случае ответа «нет» может быть задан
другой вопрос: «На улице жарко?» — и будет рекомендована соответствующая
одежда. Так вы будете перебирать варианты, пока не будет найден лучший из них.
Дерево принятия решений также может предсказать, купит ли клиент тот или
иной товар. Например, оно может спросить: «Покупал ли клиент что-нибудь
за последний месяц?» Если ответ «да», клиент с большой вероятностью может
сделать новую покупку в ближайшем будущем. В случае ответа «нет» дерево
может учесть другие факторы (например, недавние посещения сайтов или клики
рекламных объявлений) для прогнозирования покупательского поведения, по-
могая продавцам предоставить клиенту подходящую рекламу и предложения.
Случайный лес
Как подсказывает название, модель случайного леса работает с лесом, в котором
каждое дерево является деревом принятия решений, голосующим за результат.
Каждому дереву выделяется случайное подмножество данных, и оно старается
принять лучшее решение. Затем все деревья «голосуют», и на основании ре-
зультатов выбирается окончательный ответ. Такой подход часто обеспечивает
более точные и стабильные прогнозы, чем отдельное дерево принятия решений.
В финансах модель случайного леса могут использоваться для решения о том,
одобрить или отклонить заявку на кредит. Деревья учитывают, например, такие
параметры, как кредитный рейтинг, доход и текущая задолженность клиента.
Окончательное решение, принимаемое большинством голосов всех деревьев,
получается более точным и надежным, чем с одной моделью; таким образом
сокращается риск одобрения кредитов неблагонадежным заемщикам.
Модель К ближайших соседей (k-NN)
Использование модели к ближайших соседей (k-NN) похоже на сравнение не-
знакомого предмета с похожими предметами, которые вам уже известны, чтобы
понять его качества. Если вы нашли фрукт, который еще никогда не видели, вы
можете решить, будет ли он кислым или сладким, сравнивая его с похожими
фруктами, вкус которых вам знаком. Если он похож на другие сладкие фрукты,
вы ожидаете, что он тоже будет сладким.
Data science и машинное обучение 501
Метод k-NN широко применяется в рекомендательных системах — например, на
сайтах интернет-магазинов. Если пользователь приобрел конкретный продукт,
k-NN находит похожие продукты, купленные другими клиентами, и рекомен-
дует их пользователю. Представим, что пользователь приобрел детективный
роман. В таком случае k-NN находит других клиентов, купивших ту же книгу,
и рекомендует другие книги, купленные этими клиентами.
Метод опорных векторов (SVM)
Метод опорных векторов (SVM, Support Vector Machines) — алгоритм принятия
решений, который стремится по возможности отделить друг от друга разные
группы объектов. Представьте, что перед вами большой стол, на одной стороне
которого лежат яблоки, а на другой — бананы. SVM пытается найти самую ши-
рокую возможную линию (или полосу), разделяющую два вида фруктов, чтобы
яблоки были по одну сторону от этой линии, а бананы — по другую и они не
смешивались друг с другом.
Метод SVM эффективно работает в области распознавания рукописного текста.
Например, если вы напишете число (допустим, «4»), SVM поможет компьютеру
решить, действительно ли это «4» или что-то другое — скажем, «9». Для этого
SVM изучает много примеров того, как люди записывают эти цифры, и на-
ходит лучшую границу, отделяющую «4» от «9», помогая точно распознавать
рукописные цифры.
Нейронные сети
Нейронная сеть (или нейросеть) работает как мини-мозг внутри компьютера,
который учится на множестве примеров для принятия решений. Когда вы на-
чинаете кататься на велосипеде, вы часто падаете, но со временем учитесь дер-
жать равновесие и крутить педали, понимая, что пошло не так в предыдущих
попытках. Нейросети учатся аналогично — исправляя прошлые ошибки, чтобы
принять лучшие решения в следующий раз.
Например, платформы социальных сетей используют нейросети для идентифи-
кации и отметки людей на фотографиях. В процессе обучения сеть анализирует
множество изображений людей и замечает такие признаки, как, например, форма
носа и цвет глаз. При отправке новой фотографии эти признаки сравниваются
с накопленной информацией, и нейросеть делает предположение относительно
того, кто на ней изображен.
Кластеризация методом к-средних
Кластеризация методом к-средних используется для группировки похожих точек
данных. Представьте, что вы устраиваете большую вечеринку и хотите объединить
друзей с похожими интересами в группы (кластеры), чтобы они не скучали. Вы
пробуете разные способы группировки, пытаясь добиться того, чтобы участники
групп были как можно ближе друг к другу и все хорошо провели время.
502 Глава 13. Архитектура машинного обучения
Популярное применение кластеризации методом k-средних — сегментация
клиентов для стратегий маркетинга. Компании могут применять кластеризацию
методом k-средних для группировки клиентов в зависимости от их покупатель-
ского поведения. Например, в одном кластере могут быть собраны клиенты,
которые покупают часто, но тратят мало, а в другом — те, что покупают редко,
но совершают большие покупки. На разные группы могут быть направлены
разные стратегии маркетинга для максимизации продаж.
XG Boost
XGBoost учится на прошлых ошибках и становится умнее с каждым решением.
Если вы решаете математические задачи и совершаете ошибку в одной из них,
XGBoost оценивает, понимает, что пошло не так, и запоминает ошибку, чтобы
в следующий раз избежать ее в похожей задаче.
В кредитной отрасли XGBoost широко применяется для прогнозирования
рисков невозврата кредитов. Многие факторы — доход, возраст, кредитная
история клиента — используются для прогнозирования невозврата. Если для
потенциального заемщика высока вероятность невозврата, его заявку могут
отклонить, чтобы свести к минимуму риск для банка.
Рассмотренные алгоритмы лежат в основе многих проектов МО. Они выбира-
ются на основании поставленной задачи и типов обрабатываемых данных (текст,
графика, числа). Некоторые из алгоритмов — например, нейросети — требуют
больших вычислительных ресурсов и данных, тогда как другие (например,
деревья принятия решений или модель к ближайших соседей) могут быть при-
менимы даже с небольшими датасетами.
Наше знакомство с МО продолжается. В следующем разделе будут рассмотрены
популярные инструменты и фреймворки МО.
Популярные инструменты и фреймворки
машинного обучения
МО реализуется при помощи различных инструментов и фреймворков, предна-
значенных для разных этапов разработки моделей МО — начиная с обработки
данных и проектирования алгоритмов и заканчивая обучением и развертыва-
нием моделей.
Ниже представлены некоторые популярные инструменты для подготовки
и анализа данных.
• NumPy: основная библиотека Python для научных вычислений. Библиотека
NumPy (Numerical Python) содержит объекты многомерных массивов и набор
операций для работы с ними.
©Массивом называется коллекция элементов данных одного типа, хранящихся
в смежных областях памяти.
Data science и машинное обучение 503
NumPy упрощает и повышает эффективность числовых и логических опера-
ций с большими наборами данных. Представьте торговую компанию, которая
хочет вычислить средний объем продаж для анализа эффективности и вы-
бора будущей стратегии. У компании имеются данные ежедневных продаж,
хранящиеся в числовом формате. При помощи NumPy компания сможет
легко вычислить средние продажи за месяц; для этого она размещает данные
ежедневных продаж в массиве, суммирует и делит на количество дней.
• Pandas: эта библиотека предоставляет пользователям Python простые,
высокопроизводительные структуры данных и функции анализа данных.
В частности, Pandas предоставляет Series и DataFrames — две важнейшие
структуры данных для Python, построенные на базе NumPy.
Series представляет собой столбец, a DataFrame - многомерную таблицу,
состоящую из столбцов.
Функциональность Pandas упрощает очистку, анализ и визуализацию дан-
ных. Представьте, что продуктовый магазин хочет проанализировать свои
данные продаж, чтобы понять, какие продукты продаются лучше всего, а ка-
кие подолгу залеживаются на полках. У магазина имеется большой датасет
с информацией о каждой операции, включая название продукта, проданное
количество и цену. При помощи Pandas они смогут легко оперировать этими
данными, определить общие продажи по каждому продукту, отсортировать
их, а затем найти самые популярные позиции.
• Scikit-learn: эффективный и несложный инструмент прогнозного анализа
данных, работающий в сочетании с Pandas и NumPy. В Scikit-learn поддер-
живаются многие методы обучения с учителем и без учителя. Scikit-learn
широко применяется в МО, обычном и глубоком анализе данных и содержит
множество встроенных инструментов для выбора модели, оценки, импорта
и улучшения данных. Представьте, что банк хочет спрогнозировать, нарушит
ли новый клиент свои кредитные обязательства. У банка имеются историче-
ские данные по предыдущим клиентам: возраст, зарплата, семейное положе-
ние, наличие невыплаченных кредитов в прошлом. При помощи Scikit-learn
банк может построить модель (например, дерево решений, логистическую
регрессию или другой подходящий алгоритм), которая обучается на этих
данных, а затем воспользоваться обученной моделью для прогнозирования
вероятности того, что новый клиент не вернет кредит.
Назовем популярные инструменты и фреймворки визуализации данных.
• Matplotlib: библиотека Python с широкой функциональностью для создания
статических, интерактивных и анимированных визуализаций. Помимо ли-
нейных графиков, точечных диаграмм, гистограмм, столбцовых, круговых
и SD-диаграмм, Matplotlib предоставляет невероятно гибкую основу для
создания широчайшего спектра визуализаций. Этот инструмент позволяет
504 Глава 13. Архитектура машинного обучения
разработчикам и специалистам data science наглядно представлять свои
данные на разных типах диаграмм, что может быть очень полезно для по-
нимания распределения и закономерностей данных, решения проблем при
отладке или визуализации отношений между данными. Представим, что
учитель хочет наглядно представить оценки учеников в классе, чтобы быстро
выделить общую успеваемость и статистические отклонения. При помощи
Matplotlib учитель может строить различные диаграммы (круговые, точечные,
гистограммы и т. д.) для представления распределения оценок в доступном
и легко воспринимаемом визуальном формате.
• Seaborn: библиотека визуализации статистических данных на базе Matplotlib,
предоставляющая высокоуровневый интерфейс для построения профессио-
нальных графиков. Seaborn содержит встроенные темы оформления и цве-
товые палитры для быстрого создания привлекательных и содержательных
диаграмм. Seaborn особенно хорошо подходит для визуализации сложных
наборов данных с несколькими переменными благодаря макетам с несколь-
кими диаграммами, а также функциональности наглядного представления
отношений между несколькими переменными. Представьте, что торговая
компания хочет понять поведение своих покупателей по ряду категорий
товаров за некоторый период времени. С Seaborn аналитики могут построить
тепловую карту для наглядного представления частоты покупки по разным
категориям продуктов за разные месяцы, что позволит быстро получить
представление о тенденциях и покупательских предпочтениях.
• Инструменты бизнес-аналитики (BI): такие инструменты бизнес-аналитики,
как Tableau, Microsoft Power BI, Amazon QuickSight и MicroStrategy, исполь-
зуются для преобразования необработанных данных в доступный формат.
Эти инструменты помогают наглядно представить, понять и принять решения
относительно имеющихся данных. В отличие от других упомянутых средств,
эти инструменты обладают графическим интерфейсом, где пользователи
могут перетаскивать элементы для анализа данных. Это особенно привлека-
тельно для пользователей, не умеющих программировать. BI-инструменты
могут подключаться к разным источникам данных, формируя полезные
выводы в реальном времени. Они позволяют создавать и публиковать даш-
борды, представляющие собой интерактивные визуализации со встроенной
аналитикой. Например, сеть ресторанов хочет оптимизировать свою цепочку
поставок и меню на основании поведения клиентов и сезонных тенденций.
При помощи ВI-инструмента компания может наглядно представить дан-
ные о продажах по разным измерениям (время, демографические признаки
клиентов, категории продуктов), выявить в них закономерности и получить
информацию для принятия решений.
Перечислим популярные инструменты и фреймворки для разработки и об-
учения моделей.
• TensorFlow: полнофункциональная платформа с открытым исходным ко-
дом, предназначенная для решения целого спектра задач МО. TensorFlow
Data science и машинное обучение 505
поддерживает разные API для построения, обучения и развертывания ИИ-
моделей. Ключевая особенность TensorFlow — возможность построения
графов потоков данных. Такие графы показывают, как данные перемещаются
по разным этапам обработки (узлам). На графах каждый узел обозначает
математическую операцию, а соединения между узлами (ребра) представ-
ляют тензоры — многомерные массивы данных. TensorFlow предоставляет
инструменты разработчика для применения крупномасштабного МО, а также
обширную библиотеку для удобного изучения и разработки ИИ-мод ел ей,
подходящую как новичкам, так и экспертам. Пример: учреждение здраво-
охранения решает использовать МО для прогнозирования заболеваний
на основании метрик пациента: возраста, генетических особенностей, веса
и вредных привычек. Такая организация может воспользоваться TensorFlow
для построения модели нейросети, которая учитывает все эти факторы и про-
гнозирует вероятность заболеваний.
• PyTorch: популярность этой библиотеки МО обусловлена ее гибкостью,
простотой использования и динамическим графом вычислений, особенно
полезным для глубокого обучения. Разработчики, исследователи и специа-
листы по data science используют ее как в исследованиях, так и в рабочем
коде. Динамический граф вычислений позволяет изменять поведение сети
на ходу, а библиотека предоставляет богатый API для различных задач МО:
классификации, регрессии, обучения с подкреплением и т. д. Представим,
что интернет-магазин хочет создать чат-бота для улучшения взаимодействия
с пользователями. При помощи PyTorch можно разработать модель глубокого
обучения, которая понимает язык пользователей и дает полезные и точные
ответы на их вопросы в реальном времени.
• Keras: библиотека с открытым кодом, предоставляющая удобный API для
построения и тренировки моделей глубокого обучения. Может работать на
базе других популярных библиотек МО (таких, как TensorFlow), что делает
ее исключительно гибкой. В частности, популярность Keras обусловлена про-
стотой и удобством использования в экспериментах. С Keras специалисты
data science и разработчики могут преобразовать свои идеи в практические
результаты с минимальной задержкой, что очень важно в инновационных
проектах. Возьмем компанию розничной торговли, которая рекомендует
товары покупателям на основании их прошлой истории покупок. Компания
может воспользоваться Keras для построения рекомендательной системы;
система анализирует закономерности покупок и предлагает товары, которые
будут приобретены с большей вероятностью.
• MLlib (Apache Spark): библиотека МО, являющая частью Apache Spark;
она спроектирована с учетом масштабирования для потребностей Big Data.
MLlib предоставляет различные алгоритмы МО, в том числе классифика-
цию, регрессию, кластеризацию и коллаборативную фильтрацию, а также
инструменты для выбора и оценки модели. Она также включает API для
сохранения моделей с целью последующего использования. Библиотека
506 Глава 13. Архитектура машинного обучения
MLlib разработана для эффективного выполнения крупномасштабных за-
дач МО. С учетом своих возможностей распределенных вычислений MLlib
может быстро обрабатывать огромные объемы данных, что особенно ценно
для сценариев, где критически важны анализ данных и обучение моделей
в больших масштабах. Более того, MLlib может использоваться с разными
источниками данных и форматами, предоставляя гибкость при работе с раз-
личными типами данных. Пример: финансовая компания, которая хочет вы-
являть мошеннические операции по кредитным картам в режиме реального
времени. При помощи MLlib аналитики могут обрабатывать огромные объ-
емы данных о транзакциях для обучения моделей, выявляющих необычные
закономерности покупок или аномальные транзакции, свидетельствующие
о возможном мошенничестве. Такие модели делают возможным обнаружение
мошеннических действий и их блокировку в реальном времени.
Назовем популярные инструменты и фреймворки для развертывания моделей.
• Docker: платформа упрощает создание, развертывание и запуск приложений,
использующих контейнеры. Docker не является инструментом МО как тако-
вым, но очень полезна для эффективного и последовательного развертывания
моделей и приложений МО. Docker позволяет разработчикам и специалистам
по data science упаковать приложение вместе со всеми его зависимостями
(библиотеками, инструментами и скриптами) в контейнер. Контейнер может
передаваться и запускаться в разных вычислительных средах; это означает,
что приложение будет одинаково работать независимо от того, где оно вы-
полняется. Представьте, что команда разработчиков создает приложение
МО для прогнозирования биржевых котировок. В нее входят специалисты
по data science, которые используют различные инструменты и библиотеки
для создания моделей, и инженеры, которые строят приложение с примене-
нием разных технологий. При помощи Docker они могут создать связанный
рабочий процесс, в рамках которого все работают в согласованной среде; это
гарантирует, что модель и приложение будут одинаково вести себя во время
разработки, тестирования и развертывания, хотя они и разрабатывались
с применением разных инструментов.
• Flask: микрофреймворк, написанный на Python. Flask прост в изучении и ис-
пользовании, вследствие чего хорошо подходит для начинающих, но в нем от-
сутствует дополнительная функциональность (например, проверка форм или
уровни абстракции баз данных), которую может обеспечить полностековый
фреймворк. С другой стороны, вследствие своей простоты и удобства Flask
пользуется популярностью для развертывания облегченных веб-приложений
и API, особенно в сообществе data science и МО. Пример сценария: специа-
лист по data science разработал модель МО, предсказывающую, является ли
сообщение спамом. Эта модель может использоваться в веб-приложении, где
пользователь отправляет сообщение, а приложение определяет, является ли
оно спамом. При помощи Flask специалист по data science может создать про-
стой веб-сервер, который получает текст сообщения, использует модель МО
Data science и машинное обучение 507
для определения того, является ли оно спамом, а затем возвращает результат
пользователю, — и все это через веб-интерфейс.
Перечислим популярные интегрированные среды разработки (IDE).
• Jupyter Notebook: веб-приложение с открытым исходным кодом; позволяет
создавать и распространять интерактивные документы. Эти документы могут
содержать живой код, формулы, визуализации и пояснительный текст, в ре-
зультате чего они становятся гибкими инструментами для анализа данных,
научных исследований, а также в области образования. Jupyter поддерживает
разные языки (Python, R, Julia и т. д.) и широко применяется при очистке
данных, статистическом моделировании, МО и во многих других областях
благодаря своей интерактивной вычислительной среде. Jupyter занимает
важное место в data science, академических исследованиях и научных вычис-
лениях, позволяя создавать воспроизводимые аналитические исследования
и наглядно представлять результаты с использованием визуализаций и со-
проводительного текста. Допустим, биолог хочет проанализировать данные
о разных видах птиц и путях их миграции. Он может воспользоваться блок-
нотом Jupyter для написания кода Python, который загружает данные, на-
глядно отображает закономерности миграций и, возможно, даже использует
МО для предсказания будущих периодов или путей миграции на основании
исторических данных.
• RStudio: IDE с открытым исходным кодом для языка статистических вы-
числений и графики R, которая работает со стандартной версией R, а также
поддерживает облачные версии R. RStudio предоставляет мощную функцио-
нальность для разработки скриптов, визуализации данных и статистического
анализа, в полной мере раскрывая возможности языка R. Представьте, что
торговая компания хочет понять покупательское поведение своих клиентов.
При помощи RStudio аналитик данных может получить данные продаж,
применить статистический анализ и создать визуализации (точечные диа-
граммы, гистограммы, столбцовые диаграммы) для выявления тенденций,
популярных товаров и пиковых периодов покупок, возможно с применением
МО для прогнозирования будущих продаж.
• Apache Zeppelin: среда с открытым исходным кодом на базе схемы блокнота,
сходная с Jupyter; позволяет инженерам, аналитикам данных и специалистам
по data science разрабатывать, организовывать, выполнять и распространять
рабочие процессы и совместно выполнять код. Zeppelin поддерживает раз-
ные бэкенды обработки данных (такие, как Apache Spark, Python и JDBC).
Пользователи могут создавать управляемые данными интерактивные до-
кументы с возможностью совместной работы на Scala, Python, SQL и т. д.
Сильные стороны Zeppelin — встроенные визуализации данных и некоторые
интеграции, недоступные по умолчанию для пользователей Jupyter. Возьмем
сценарий из сектора здравоохранения: аналитики хотят исследовать данные
пациентов, чтобы понять закономерности вспышек эпидемий. При помощи
Zeppelin они могут в интерактивном режиме исследовать наборы данных,
508 Глава 13. Архитектура машинного обучения
интегрировать разные бэкенды обработки данных и создавать визуализации:
тепловые карты, линейные графики и т. д. — для наглядного представления
вспышек заболеваний по географическим регионам или временным осям.
Zeppelin, RStudio и блокноты Jupyter — самые популярные среды для инженеров
данных, в которых можно выполнять обнаружение данных, очистку, обогащение,
пометку и подготовку для обучения модели МО.
Поскольку облако становится основной платформой для обучения моделей МО,
рассмотрим некоторые доступные облачные платформы МО.
Машинное обучение в облаке
Разработка моделей МО сложна и обходится дорого. На каждом шаге рабочего
процесса МО существуют препятствия — от однообразных и отнимающих много
времени операций сбора и подготовки данных до выбора правильного алгорит-
ма МО, что часто происходит методом проб и ошибок, и продолжительного
обучения, которое приводит к еще более высоким затратам. Затем необходимо
настроить модель, и цикл настройки может быть очень долгим и требовать
тысяч комбинаций. За развернутой моделью необходимо наблюдать, а затем
масштабировать ее и управлять ее эксплуатацией.
Для решения этих задач все основные провайдеры публичных облачных плат-
форм предоставляют платформу МО, которая упрощает обучение, настройку
и развертывание моделей МО и имеет низкую стоимость. Например, Amazon
SageMaker — одна из самых популярных платформ, предоставляющих сквозные
сервисы МО. В состав SageMaker входит интегрированный набор инструментов,
собранных в одной среде SageMaker Studio. Пользователи могут мгновенно за-
пускать среды Jupyter Notebook и JupyterLab через SageMaker Studio. SageMaker
также предоставляет полное управление экспериментами, подготовку данных,
автоматизацию и координацию пайплайнов для повышения эффективности ра-
боты аналитиков данных. SageMaker также предлагает полностью управляемую
платформу RStudio — одну из самых популярных IDE среди разработчиков R
для МО и проектов из области data science. SageMaker предоставляет полностью
управляемые серверы в облаке и другую функциональность управляемых инфра-
структур. Начиная с заданий распределенного обучения и даже развертывания
моделей, SageMaker берет на себя решение всех проблем масштабирования,
установки исправлений, высокой доступности и т. д., связанных с построением,
обучением и размещением моделей.
Похожие платформы — Google Cloud AI от GCP с разными сервисами для про-
ведения экспериментов МО и Azure ML Studio от Microsoft Azure.
Кроме управляемых платформ МО, готовые к использованию сервисы ИИ
предоставляют и облачные платформы. Сервисы ИИ позволяют разработчику
легко наделить интеллектом любое приложение без обязательных навыков про-
граммирования моделей МО. Предварительно обученные модели предоставляют
Построение архитектуры машинного обучения 509
готовый интеллект для приложений и рабочие процессы, которые помогают
персонализировать взаимодействие с пользователями, предсказывать бизнес -
метрики, переводить текст, извлекать смысловую нагрузку из документов и т. д.
Например, AWS предоставляет сервис Amazon Comprehend AI с заранее обу-
ченными моделями, поддерживающими обнаружение ключевых фраз и анализ
тональности на разных языках.
Облако все чаще используется в качестве основной платформы для фундамен-
тальных моделей генеративного ИИ, предлагая экономичную и масштабируемую
среду тестирования и развертывания этих систем ИИ. Фундаментальные модели
обучаются на огромных датасетах и могут настраиваться под конкретные задачи,
что делает их гибкими инструментами, подходящими для широкого спектра
приложений. Благодаря своей масштабируемости и доступности облако стано-
вится идеальной средой для работы с этими большими моделями, интенсивно
расходующими ресурсы. Доступны как фундаментальные модели с открытым
исходным кодом, так и коммерческие модели генеративного ИИ — для разных
потребностей и бюджета.
Доступность фундаментальных моделей генеративного ИИ в облаке позволяет
бизнесу и разработчикам пользоваться расширенными возможностями новей-
ших И И-технологий без необходимости крупных вложений в вычислительную
инфраструктуру. Например, Amazon Bedrock с API позволяет использовать
сторонние фундаментальные модели таких компаний, как stability.ai, Meta,
Mistral, Anthropic, Amazon и AI21. Azure предоставляет доступ API к OpenAI
GPT-4, a GCP — к своей фундаментальной модели Gemini. Эти модели более
подробно рассматриваются в главе 14 «Архитектура генеративного ИИ».
Специалисты по data science могут воспользоваться управляемыми облачными
средами для ускорения подготовки данных и обучения модели. Когда эти про-
цессы будут завершены, они могут развернуть модель одним щелчком и начать
предоставлять аналитические результаты по протоколу HTTP.
Рассмотрим некоторые важные факторы, которые необходимо учитывать при
проектировании архитектуры МО.
Построение архитектуры машинного обучения
Создание надежного и масштабируемого рабочего процесса из разрозненного на-
бора кода — сложная и трудоемкая задача, и многие специалисты по data science
не обладают соответствующим опытом. Рабочий процесс МО можно определить
как координируемую последовательность из нескольких этапов. Специалисты по
data science и разработчики МО должны сначала упаковать разные фрагменты
кода, а затем указать порядок, в котором эти фрагменты должны выполняться,
отслеживая также код, данные и зависимости параметров модели между этапами.
Дополнительная сложность рабочих процессов МО требует мониторинга из-
менений в данных, используемых для обучения и прогнозирования, поскольку
510 Глава 13. Архитектура машинного обучения
изменения в данных могут создать смещение, которое приведет к неточным про-
гнозам. Кроме данных, специалисты по data science и разработчики МО должны
отслеживать и прогнозы модели, чтобы убедиться в их точности и отсутствии
смещения к некоторым результатам со временем. Как следствие, на то, чтобы
добиться выполнения отдельных фрагментов кода в правильной последователь-
ности и именно так, как ожидалось, может уйти несколько месяцев.
Архитектуры МО должны защищать артефакты модели и предоставлять
функциональность самообслуживания для ее разработки и обучения. Для ар-
хитектуры МО крайне важно обеспечить автоматизированное, всеобъемлющее
документирование всего жизненного цикла разработки модели, охватывающее
этапы разработки, обучения и развертывания.
Приложения МО также должны применять пайплайн непрерывной интеграции
и непрерывного развертывания (CI/CD), бесшовно интегрированный с система-
ми управления изменениями. Эта интеграция играет важную роль в управлении
и развертывании модели. Кроме того, среды требуют заранее определенных
конфигураций безопасности.
В следующих разделах описаны компоненты архитектуры МО на платформе
AWS, которые помогут вам понять архитектуру МО.
Другие облачные платформы МО - Azure ML Studio, H2O.ai, SAS, Databricks
и Google Al.
Подготовка и разметка
Чтобы подготовить данные для МО, необходимо выполнить их обработку:
генерацию признаков, проверку данных, оценку модели и ее интерпретацию.
В процессе генерации признаков также выполняется предварительная обработка
наборов данных для их преобразования в формат, ожидаемый алгоритмом МО.
Например, если вы работаете с датасетом, включающим даты, вы можете из-
влечь день недели, месяц и время года в отдельные признаки, так как они могут
обладать прогностической ценностью для модели. Используйте инструменты
и методы, перечисленные в предыдущем разделе, чтобы привести данные к фор-
ме, необходимой для вашей модели МО. Управляемая платформа МО — такая,
как Amazon Sage Maker — также предоставляет инструмент очистки и преоб-
разования данных (Data Wrangler) и функциональность хранилища признаков
для упрощения задачи обработки данных. SageMaker Data Wrangler упрощает
подготовку данных для МО, предлагая визуальный интерфейс для загрузки,
объединения, очистки и преобразования данных. Этот инструмент помогает
выполнить распространенные операции подготовки данных без написания кода,
ускоряя процесс и сокращая риск ошибок.
SageMaker Feature Store — централизованный репозиторий для хранения, обмена
и управления курируемой функциональностью для моделей МО. Таким образом
Построение архитектуры машинного обучения 511
обеспечивается согласование разных моделей и сокращаются избыточные усилия
по генерации признаков. Feature Store помогает поддерживать согласованный
набор признаков для обучения и инференса, что повышает эффективность мо-
дели и упрощает ее обслуживание.
Разметка данных — важный этап обработки данных. Этот процесс помогает
организовать и сконструировать точные наборы данных для МО. Для упро-
щения задачи можно воспользоваться сторонними сервисами (например,
Labelbox, CrowdAI, Docugami, Scale и т. д.), предназначенными для разметки
изображений и других видов аннотирования данных. Кроме того, такие плат-
формы, как Amazon SageMaker Ground Truth, автоматизируют разметку данных
изображений.
Когда данные готовы, наступает очередь следующего этапа — выбора подходя-
щего алгоритма и построения модели.
Выбор и построение модели
Прежде чем создавать модель МО, необходимо четко понять бизнес-задачу; это
поможет выбрать подходящий алгоритм. Как говорилось в предыдущем разделе,
можно использовать различные алгоритмы и фреймворки МО — с учителем
или без учителя. Выбор может зависеть от доступных данных. После того как
вы определились с подходящим для своего сценария алгоритмом МО, понадо-
бится платформа для разработки модели и ее обучения.
Специалисты по data science чаще всего выбирают Jupyter Notebook и RStudio
в качестве платформ для построения моделей МО. Для запуска Jupyter Notebook
или RStudio Workbench можно воспользоваться такими облачными платформа-
ми, как Amazon SageMaker. AWS предоставляет SageMaker Studio и RStudio —
визуальный интерфейс на базе веб-технологий, где все основные шаги разработки
МО уже проделаны за вас.
Далее можно выбрать один из нескольких встроенных алгоритмов МО, под-
ходящих для различных задач, или воспользоваться облачными моделями
и алгоритмами, чтобы побыстрее начать работу.
Следующий шаг — обучение и настройка модели. Рассмотрим его более подробно.
Обучение и настройка модели
Для ускорения процесса обучения желательно использовать распределенный
вычислительный кластер. Такая конфигурация позволяет распределить обучаю-
щую рабочую нагрузку по нескольким вычислительным ресурсам, значительно
ускоряя обучение. Применяя такой кластер, можно организовать параллельные
вычисления, то есть одновременную обработку разных частей обучающих дан-
ных. В результате обучение модели завершается быстрее, а результат, который
может использоваться приложениями, становится доступным раньше. Такой
подход не только улучшает эффективность, но и делает возможной обработку
512 Глава 13. Архитектура машинного обучения
больших наборов данных, что позволяет разрабатывать более точные и надежные
модели МО. Настройка модели, также называемая настройкой гиперпараметров,
чрезвычайно важна для получения точных результатов.
Необходимо найти самую эффективную версию модели. Для этого запускают
разные обучающие задания с имеющимся датасетом, используя выбранный
алгоритм и разные диапазоны гиперпараметров. После этого выбираются пра-
вильные значения гиперпараметров, которые формируют самую эффективную
модель в соответствии с выбранной метрикой.
Для настройки модели необходимо предусмотреть средства отладки, которые
помогают определять метрики реального времени на этапе обучения: точность
обучения и проверки, матрицы ошибок, градиенты обучения и т. д. Эти метрики
необходимы для повышения точности модели. Для этой же цели важно вести
соответствующую документацию. В ней необходимо сохранять параметры ввода,
конфигурации и результаты и классифицировать их как разные эксперименты.
Такая структура позволяет эффективно находить проделанные эксперимен-
ты по их характеристикам, анализировать предыдущие эксперименты по их
результатам и наглядно сравнивать результаты разных экспериментов, чтобы
делать выводы для дальнейших корректировок и улучшений. Многие управ-
ляемые платформы МО — например, Amazon SageMaker — предоставляют эту
функциональность.
Amazon SageMaker также предлагает Autopilot — функциональность, которая
автоматизирует некоторые области разработки модели. Autopilot анализирует
необработанные данные и применяет к ним методы обработки признаков. Затем
Automaker выбирает наиболее подходящие алгоритмы, проводит обучение, на-
страивает разные модели и отслеживает их эффективность. Модели ранжируются
по метрикам производительности.
После инициализации модели ее необходимо развернуть и управлять ею в ра-
бочей среде, чтобы получать ценные инсайты и желаемые результаты.
Развертывание модели и управление ею
Чтобы реализовать прогнозирование в режиме реального времени или пакетном
режиме, необходимо развернуть обученную модель МО в продакшен-среде. Ре-
ализуйте автомасштабирование экземпляров МО в разных местоположениях,
чтобы обеспечить высокую избыточность и установить эндпоинты RESTful
HTTPS для приложения. Приложение должно быть настроено так, чтобы
использовать вызов API к эндпоинту МО для обеспечения низкой задержки
и высокой скорости обработки. Такой архитектурный подход облегчает быструю
интеграцию новых моделей в приложение, и это упрощает процесс, потому что
изменения в модели необязательно приводят к изменениям в коде приложения.
Данные подвержены быстрым изменениям из-за таких факторов, как сезон-
ность или непредвиденные события. По этой причине очень важно непрерывно
Построение архитектуры машинного обучения 513
отслеживать модель на предмет как точности, так и актуальности для бизнеса.
Важный фактор, который может повлиять на точность развернутых моделей:
отличаются ли данные, на которых генерируются прогнозы, от данных, ис-
пользовавшихся для обучения модели? Например, изменение экономических
условий может привести к изменению процентных ставок, которое, в свою
очередь, может влиять на прогнозы покупок для домохозяйств. Это явление
называется дрейфом концепции: закономерности и корреляции, на которых
обучалась модель, перестают быть истинными в текущей среде данных. Для
решения этой проблемы необходимо настроить автоматическое обнаружение
дрейфа концепции в развернутых моделях и выдачу подробных оповещений,
которые помогают обнаружить истинный источник проблемы.
Совместимость модели — еще один критически важный фактор на этапе раз-
вертывания. После построения и обучения модели (например, с использованием
MXNet, TensorFlow, PyTorch или XGBoost) можно выбрать целевую аппарат-
ную платформу — Intel, NVIDIA или ARM. Необходимо компилировать обу-
ченные модели МО так, чтобы они оптимально и эффективно выполнялись
при развертывании компилируемых моделей на периферийных устройствах.
Это гарантирует, что модели будут не только высокопроизводительными, но
и экономичными.
Необходимо поддерживать возможность запуска крупномасштабных приложе-
ний МО, которые могут решать такие задачи, как распознавание образов, рас-
познавание речи, NLP, персонализация и обнаружение попыток мошенничества.
По мере продвижения по этапам построения и развертывания моделей МО очень
важно сформировать понимание того, как производить их точную настройку
и адаптировать их для эффективного развертывания и эксплуатации — особен-
но в приложениях, требующих обработки и реагирования в реальном времени.
Рассмотрим эталонную архитектуру, в которой объединяются все компоненты.
Референсная архитектура МО
На рис. 13.3 изображен рабочий процесс одобрения банком заявки на получение
кредита, реализованный на базе облачной платформы AWS.
Данные клиента поглощаются в облаке, а фреймворк МО принимает решение
по заявке.
При проектировании этой архитектуры необходимо руководствоваться не-
сколькими фундаментальными принципами.
• Рабочий процесс обучения
1. Наборы данных входят в процесс с использованием S3. Это могут быть
необработанные входные данные или данные, прошедшие предварительную
обработку, из локальных наборов данных.
2. Ground Тruth используется для создания высококачественного обучающего
датасета для моделей МО. При необходимости сервис Ground Truth может
произвести разметку данных.
514
Глава 13. Архитектура машинного обучения
Direct
Connect
Локальная
среда
Шлюз API
Рис. 13.3. Архитектура МО в облаке AWS
Пользовательский
интерфейс
а
Пользователь
3. AWS Lambda может использоваться для интеграции, подготовки и очистки
данных перед передачей датасета в SageMaker.
4. Специалисты по data science взаимодействуют с SageMaker для
обучения и тестирования их моделей. Образы Docker, используемые
SageMaker, хранятся в ECR; это могут быть специализированные образы
с нестандартными инструментариями, созданными на этапах процесса
сборки, или же заранее построенные образы Amazon.
5. Артефакты модели, которые должны использоваться как часть этапа
развертывания, выводятся в S3. Вывод модели SageMaker также может
использоваться для разметки данных с использованием Ground Truth.
Модели, построенные заранее и прошедшие обучение локально или на
других платформах, могут быть помещены в бакет артефактов модели
в S3 и развернуты с использованием SageMaker.
6. AWS Lambda может запускать процесс утверждения после того, как новый
артефакт модели помещается в бакет S3.
7. Amazon SNS (Simple Notification Service) может использоваться
для предоставления автоматического или ручного, основанного на
человеческом вмешательстве процесса утверждения, чтобы развернуть
итоговую модель. Поддерживающая функция Lambda получает выходные
данные от SNS для развертывания модели.
Принципы проектирования архитектуры машинного обучения 515
8. DynamoDB хранит все метаданные, действия и другие связанные данные
модели для целей аудита.
9. Чтобы разместить итоговую модель, развертывается эндпоинт
с соответствующей конфигурацией как часть последнего этапа рабочего
процесса.
• Рабочий процесс сборки
10. Экземпляры блокнота SageMaker используются для подготовки
и обработки данных, а также для обучения и развертывания моделей
МО. К этим блокнотам можно обращаться через эндпоинт VPC для
сервиса SageMaker.
11. CodeCommit предоставляет репозиторий исходного кода, инициируя
задания сборки, необходимые для всех нестандартных образов Docker,
используемых SageMaker.
12. Сервис CodePipeline управляет сквозным пайплайном сборки
нестандартных образов Docker и использует сервис CodeBuild для этапа
сборки/тестирования.
13. CodeBuild строит нестандартный образ Docker и проводит его юнит-
тестирование, после чего помещает его в Amazon ECR (процесс может
управляться централизованно или бизнес-функциями, которым требуются
инструменты).
• Рабочий процесс развертывания
14. Поскольку эндпоинты SageMaker являются приватными, Amazon API
Gateway предоставляет пользователям эндпоинт модели для получения
инференса.
Пакетные задания преобразований обычно нужны для получения инференса на
всем датасете. Результат пакетного задания, использующего обученную модель
и датасет, сохраняется в S3. Кроме того, можно применять SageMaker Model
Monitor для отслеживания рабочих моделей и отправки уведомлений при воз-
никновении проблем с качеством.
В этом разделе вы узнали об архитектуре МО с пайплайном CI/CD. В следующем
разделе будут рассмотрены принципы проектирования архитектуры МО.
Принципы проектирования архитектуры
машинного обучения
Проектирование эффективной архитектуры МО требует стратегического
подхода и особого внимания к масштабируемости, удобству обслуживания,
эффективности и надежности. Рассмотрим некоторые принципы проекти-
рования, которыми часто руководствуются профессионалы при разработке
архитектур МО.
516
Глава 13. Архитектура машинного обучения
Модульность
В соответствии с принципом модульности (modularity) система МО разделяется
на отдельные взаимозаменяемые компоненты, или модули, каждый из которых
отвечает за выполнение некоторой функции. Например, в модели МО один
модуль может отвечать за поглощение данных, другой — за предварительную об-
работку, третий — за обучение модели и еще один — за предоставление прогнозов.
Пример — рекомендательная система для интернет-магазина: модуль погло-
щения данных может отвечать за сохранение информации о взаимодействиях
с пользователями и истории покупок, а другой модуль использует эти данные для
обучения модели, рекомендующей товары. Преимущество модульной структуры
заключается в том, что, если будет разработан более совершенный рекоменда-
тельный алгоритм, модуль обучения можно будет заменить или обновить без
нарушения работоспособности модуля поглощения данных.
Другой пример: в системе обнаружения попыток финансового мошенничества
модульность позволяет команде разработки изолировать и обновлять прогноз-
ную модель каждый раз, когда обнаруживается новая схема мошенничества, без
изменения модулей сбора данных или мониторинга транзакций. Такой подход
упрощает диагностику и целенаправленные обновления и улучшает общую
управляемость системы.
Масштабируемость
Масштабируемостью (scalability) называется способность архитектуры МО
корректно справляться с возрастанием рабочей нагрузки или пользовательско-
го спроса, обеспечивая стабильную производительность. Масштабируемость
критически важна для управления большими датасетами или значительным
возрастанием пользовательских запросов. Например, в потоковом сервисе —
таком, как Netflix — рекомендательная система должна масштабироваться,
чтобы адаптироваться к растущему количеству пользователей и их историй
просмотра без ущерба для скорости или точности рекомендаций. Масштаби-
руемость гарантирует, что работоспособность сервиса не будет нарушена и он
будет демонстрировать стабильно высокую производительность даже с ростом
объема данных и спроса.
Другой пример из реальной жизни — интернет-магазин во время распродаж
«Черной пятницы». Система должна масштабироваться, чтобы обрабатывать
и анализировать экспоненциально растущие количества транзакций и объемы
пользовательских данных.
Воспроизводимость
Необходимо обеспечить надежную воспроизводимость (reproducibility) ре-
зультатов моделей МО. Это означает, что в случае повторного обучения с теми
же данными, кодом и параметрами модель должна выдать те же результаты.
Принципы проектирования архитектуры машинного обучения 517
Платформа электронного обучения может использовать модель МО для персо-
нализации учебного контента для каждого пользователя. Если какая-то версия
модели показывает особенно точные результаты, возможность ее воспроизвести
гарантирует согласованность взаимодействий с пользователями и упрощает
будущую отладку и разработку.
Рассмотрим модель МО, предназначенную для медицинской диагностики
по данным визуализирующих обследований. Воспроизводимость означает,
что диагнозы останутся последовательными и надежными между разными
экземплярами модели, укрепляя доверие к автоматизированной системе среди
медиков и пациентов и гарантируя достоверность и проверяемость научных
исследований, использующих модель.
Контроль качества данных
Под контролем качества данных понимается реализация механизмов проверки
точности (accuracy), полноты (completeness) и надежности (reliability) данных,
передаваемых моделям МО. Для такой системы, как виртуальный помощник
с голосовым управлением, который на основе взаимодействий с пользователя-
ми непрерывно учится давать все более точные ответы, обеспечение точности
и актуальности входных данных играет ключевую роль в эффективности
обучения модели. Неверные или некачественные данные могут привести к тому,
что модель будет обнаруживать некорректные закономерности, снижая качество
пользовательского опыта.
Рассмотрим другой пример: навигационную систему беспилотного автомобиля.
Качество данных особенно важно, потому что решения, принимаемые моделью
МО на основании этих данных, напрямую влияют на безопасность и эффектив-
ность работы транспортного средства.
Г ибкость
Гибкостью (flexibility) в архитектуре МО называется способность системы легко
адаптироваться к изменениям или усовершенствованиям в технологиях, данных
и требованиях. Гибкая система может интегрировать новые источники данных,
управлять разными типами данных и адаптироваться к разным алгоритмам или
технологиям в случае необходимости. Представьте новое приложение-агрегатор,
которое использует МО для персонализации контента для пользователей. Гиб-
кость позволяет этому приложению легко адаптировать свою модель к новым
источникам данных (например, недавно появившимся новостным веб-сайтам)
или интегрировать новые типы данных (видеоролики, подкасты и т. д.) без
основательной переработки архитектуры.
Другой пример — чат-бот службы поддержки: гибкость позволяет чат-боту адап-
тировать свои ответы и стиль взаимодействия под меняющиеся пользовательские
ожидания и языковые тенденции. Представим, что модель обнаружила сдвиг
518 Глава 13. Архитектура машинного обучения
в стиле пользовательских взаимодействий или резкое увеличение частоты кон-
кретных запросов. Гибкая архитектура позволит ей интегрировать новые данные
или приспособить свои алгоритмы для улучшения пользовательского опыта.
Робастность и надежность
Обеспечение робастности (robustness) и надежности (reliability) означает,
что архитектура МО должна генерировать последовательные, обусловленные
результаты и оставаться устойчивой к изменениям во входных данных или
возмущениям системы. Например, стабильная модель МО для поставщика
электронной почты должна последовательно отфильтровывать спам независимо
от методов спам-рассылки или содержания сообщений. Она должна надежно
защищать почтовый ящик пользователя, даже если спамеры изменят свои стра-
тегии и начнут использовать другие языки и терминологию.
В автоматизированной биржевой торговле робастность и надежность моделей
МО жизненно важны для гарантий того, что торговые решения будут после-
довательными и защищенными от волатильности рынка или обманных торго-
вых операций. Система МО должна распознавать и обходить рыночный шум,
ошибочные данные или манипулятивные торговые операции, чтобы защитить
инвестиции и сохранять доверие инвесторов.
Конфиденциальность и безопасность
Конфиденциальность (privacy) и безопасность (security) подразумевают
защиту данных и модели МО от несанкционированного доступа и обеспе-
чение обработки персональных или чувствительных данных с учетом этики
и комплаенса. Например, в персональном финансовом приложении, которое
использует МО для предоставления финансовых рекомендаций, важно защи-
тить финансовые данные пользователя и обеспечить защиту прогнозов модели
от злонамеренных атак, чтобы сохранить конфиденциальность пользователей
и целостность модели.
В сценарии персонализированного маркетинга очень важно, чтобы обработка
пользовательских данных (история покупок, предпочтения, персональная ин-
формация) осуществлялась с исключительно высоким уровнем безопасности
и конфиденциальности. Модель МО, которая курирует контент персонали-
зированного маркетинга, должна соответствовать нормативам по обработке
персональных данных и быть защищенной от взлома. Такие меры сохраняют
репутацию бренда и обеспечивают соответствие юридическим требованиям.
Эффективность
Под эффективностью (efficiency) понимается достижение максимальной
производительности системы МО при минимизации используемых ресурсов.
Эффективная модель МО следит за тем, чтобы использование вычислительных
Принципы проектирования архитектуры машинного обучения 519
ресурсов, хранилища данных и других ресурсов оптимизировалось без ущерба
для качества вывода модели. В случае мобильных приложений, использующих
МО для таких функций, как распознавание образов или машинный перевод,
эффективная модель должна предоставлять быстрые и точные результаты без
избыточного расходования заряда батареи устройства или интенсивного ис-
пользования вычислительных ресурсов.
Например, обнаружение мошенничества в сетевых транзакциях в реальном
времени выводит на первый план необходимость эффективности. Модель МО
должна быстро анализировать данные транзакций и точно идентифицировать
мошеннические операции для моментальных действий или уведомлений. И все
это в сочетании с управлением вычислительными ресурсами для обработки
бесчисленных транзакций, выполняемых ежесекундно. Эффективность обеспе-
чивает быстрое и точное обнаружение попыток мошенничества без непомерно
высоких вычислительных затрат или задержки при обработке транзакций.
Интерпретируемость
Интерпретируемость (interpretability) в архитектуре МО означает, что выводы
модели понятны и объяснимы для человека. Например, медицинская платфор-
ма, которая применяет МО для содействия врачам в диагностике заболеваний,
должна предлагать интерпретации своих прогнозов, чтобы врачи понимали
обоснования предлагаемых диагнозов и, как следствие, принимали взвешенные
решения по лечению.
Другой пример: приложение МО из области кредитного скоринга. Интерпрети-
руемость исключительно важна как для конечных пользователей, которые хотят
понять, какие факторы повлияли на их кредитную оценку, так и для контрольно-
надзорных органов, следящих за тем, чтобы модель оценки не была смещенной
и соответствовала юридическим стандартам. Интерпретируемая модель МО
может пояснять, какие факторы (история транзакций, история возврата кредитов
и т. д.) влияют на оценку; таким образом обеспечивается прозрачность и фор-
мируется доверие между пользователями и контрольно-надзорными органами.
Способность работы в режиме реального времени
Под способностью работы в режиме реальном времени подразумевается способ-
ность архитектуры МО обрабатывать данные и генерировать результаты в ре-
альном или почти в реальном времени, что очень важно в сценариях, требующих
мгновенного принятия решений. Так, беспилотный транспорт применяет МО
для принятия неотложных решений на основании входных данных, получаемых
в реальном времени от разных датчиков и камер, — например, идентификации
препятствий и выбора оптимального пути. Архитектура должна обрабатывать,
оценивать и действовать на основании данных реального времени для безопасной
навигации по динамическим средам.
520 Глава 13. Архитектура машинного обучения
В службе поддержки, предоставляемой виртуальными помощниками и чат-
ботами, функциональность реального времени обеспечивает немедленную
и точную реакцию на клиентские запросы. Таким образом повышаются каче-
ство взаимодействия и удовлетворенность пользователей. Модель МО должна
распознать пользовательский ввод, обработать важные данные и сгенерировать
ответы в реальном времени, обеспечив плавное и разумное взаимодействие, даже
если запросы пользователей и диалоги различаются.
Отказоустойчивость
Отказоустойчивость (fault tolerance) подразумевает, что архитектура МО будет
поддерживать свою функциональность и генерировать разумные результаты
даже при отказе некоторых системных компонентов либо при поступлении не-
ожиданных входных данных. Например, рекомендательная система интернет-
магазина должна рекомендовать товары, даже если часть источников данных
(скажем, недавняя история просмотра) временно недоступна. Это обеспечит
непрерывность вовлечения пользователей и потенциальные продажи.
Система мониторинга промышленного оборудования на базе МО может пред-
сказывать необходимость в обслуживании и выявлять сбои. Благодаря отказо-
устойчивости система будет предоставлять полезную информацию даже в том
случае, если некоторые датчики перестанут работать или будут сообщать оши-
бочные данные. Модель МО должна выявлять такие аномалии и управлять ими,
предлагая надежную оценку работоспособности оборудования и обеспечивая
безопасную и непрерывную работу в промышленной среде.
При соблюдении этих принципов в архитектурах МО модели могут надежно
работать в различных реальных сценариях, от обеспечения безопасных и эффек-
тивных операций в отрасли до предоставления содержательных взаимодействий
в реальном времени в службе поддержки.
Машинное обучение может применяться повсюду. Например, для решения
клиентских задач: прогнозного обслуживания, предоставления точных про-
гнозов для бизнеса, формирования персонализированных рекомендаций для
конечных пользователей и т. д. Сценарии использования МО не ограничи-
ваются клиентскими задачами, но помогают контролировать 1Т-приложения
за счет оптимизации рабочей нагрузки с предиктивным масштабированием,
выявлением закономерностей в журналах, исправлением ошибок до того, как
они создадут проблемы в продакшен-среде, или прогнозирование бюджета для
инфраструктуры IT. Таким образом, архитекторы решений должны разбираться
в сценариях использования МО и связанных с ними технологиях.
Ранее в этой книге вы узнали о методологии DevOps, предназначенной для
автоматизации и практической реализации рабочей нагрузки при разработке.
По мере того как МО начинает внедряться повсеместно, методология MLOps
стала играть важную роль при изучении масштабного применения МО в рабочих
MLOps 521
системах. В следующем разделе практическая реализация рабочей нагрузки МО
с MLOps рассматривается более подробно.
MLOps
Рабочий процесс МО представляет собой комплекс операций, которые разра-
ботаны и исполняются для формирования математической модели, решающей
некую реальную задачу. Однако эти модели не обладают никакой ценностью,
пока не будут развернуты для реальной эксплуатации (а не останутся под-
тверждениями жизнеспособности концепции). Чтобы модели МО имели
практическую ценность для бизнеса, они почти всегда требуют развертывания
в продакшен-среде.
По своей сути, процесс MLOps направлен на превращение экспериментальной
модели МО в полностью функциональную рабочую систему. Практика MLOps
еще не сформировалась окончательно, она отличается от традиционной практики
DevOps уникальной природой жизненного цикла разработки МО и производи-
мых ею специфических артефактов МО. В жизненном цикле МО центральное
место занимает выявление закономерностей в обучающих данных, вследствие
чего процесс MLOps особенно чувствителен к изменениям данных, а также
колебаниям в объеме и качестве данных.
Хорошо проработанная практика MLOps должна поддерживать мониторинг
операций жизненного цикла МО, а также текущее наблюдение за моделями
в продакшен-среде. Этот двойной контроль обеспечивает эффективность как
процесса разработки, так и развернутых моделей.
Реализация MLOps позволяет организациям уверенно создавать серьезные
фреймворки MLOps без большого объема кода. Как и в отношении любой другой
рабочей нагрузки, при разработке MLOps следует применять лучшие практики
(безопасность, надежность, высокую доступность, производительность) и учиты-
вать затраты на развертывание жизненного цикла МО. Рассмотрим некоторые
принципы MLOps.
Принципы MLOps
Любые изменения в коде, обучающих данных или модели должны инициировать
процесс сборки в пайплайне разработки МО. Это гарантирует эффективную
работу модели и немедленную реакцию на изменения.
Пайплайн МО должен соответствовать следующим принципам MLOps.
• Автоматизация: развертывание моделей МО в продакшен должно быть
автоматизировано. Команде MLOps следует автоматизировать весь процесс
МО, от инженерии данных до инференса модели в продакшен-среде без руч-
ного вмешательства. Автоматизация гарантирует, что в рабочей модели не
будет пробелов в случае изменения обучающих данных и модель останется
522 Глава 13. Архитектура машинного обучения
актуальной. Пайплайн MLOps может инициировать обучение модели и ее
развертывание на основании таких событий, как календарное планирование,
отправка сообщений, мониторинг, изменения данных, а также изменения
кода обучения модели и кода приложения.
• Контроль версий: один из важнейших принципов MLOps. Версии каждой мо-
дели МО и связанного с ней скрипта должны учитываться системой контроля
версий (например, GitHub), чтобы модели оставались воспроизводимыми
и пригодными для аудита.
• Тестирование: системы МО требуют расширенного тестирования и мони-
торинга. При тестировании каждой системы МО должны учитываться как
минимум три области:
тесты признаков и данных, включающие проверку качества данных и вы-
бор правильных признаков для модели МО;
тесты разработки модели, включающие тесты бизнес-метрик, тесты акту-
альности модели и тесты проверки эффективности модели;
тесты инфраструктуры МО, включающие тесты API МО, интеграционные
тесты всего пайплайна МО, а также тесты доступности серверов обучения
и эксплуатации.
• Воспроизводимость: каждый этап рабочего процесса МО должен быть вос-
производимым, то есть результаты обучения модели МО, обработки данных
и размещения модели МО должны быть аналогичными для сходных входных
данных. Тем самым обеспечивается устойчивость системы МО.
• Развертывание: MLOps интегрирует принципы МО с культурой DevOps,
уделяя особое внимание CI/CD и непрерывному обучению / непрерыв-
ному мониторингу (СТ/СМ). Посредством автоматизации развертывания
и тестирования MLOps упрощает раннее выявление проблем, что делает
возможным быстрое внесение исправлений и итеративное обучение. Такой
метод упрощает процесс развертывания моделей МО в продакшен-среде,
благодаря чему они остаются эффективными и актуальными.
• Мониторинг: со временем производительность рабочей модели может
снизиться, например из-за дрейфа данных. В таком сценарии необходимо
непрерывное развертывание новых или обновленных моделей, чтобы пре-
пятствовать снижению эффективности или улучшать достоверность модели.
Таким образом, после развертывания модели МО следует развернуть систему
мониторинга для гарантии того, что модель МО работает в рамках ожиданий
и продолжает эффективно генерировать надежные и точные результаты. Все
это важно для поддержания общего качества и достоверности результатов,
выдаваемых приложением МО.
После рассмотрения принципов проектирования MLOps давайте рассмотрим
некоторые лучшие практики применения MLOps в рабочей нагрузке.
MLOps 523
Лучшие практики MLOps
Из-за обилия «подвижных частей» (данные, модель, код), а также сложностей
с применением МО при решении бизнес-задач реализовать MLOps может быть
непросто.
В соответствии с принципами, описанными в предыдущем разделе, существу-
ют лучшие практики, которые должны применять инженеры МО / full-stack-
специалисты по data science при развертывании решений МО в рабочей среде.
Это поможет сократить технический долг и затраты на обслуживание проектов
МО, а также извлечь из них максимальную практическую пользу. Вот некоторые
из таких лучших практик.
• Факторы проектирования: если вы хотите разработать систему МО, кото-
рую удобно обслуживать, архитектура системы должна быть модульной и по
возможности слабосвязанной. Слабая связанность (loose coupling) архитек-
туры позволяет разным командам в организации работать независимо. Это
означает, что такие команды не зависят от других команд, обеспечивающих
необходимую поддержку или услуги. В результате каждая команда работает
быстрее и эффективнее, внося свой вклад в общую ценность и производи-
тельность организации.
• Проверка данных: проверка данных играет ключевую роль в успешности
системы МО. В продакшен-среде с данными могут возникать сложности.
Например, статистические свойства рабочих данных отличаются от свойств
обучающих данных, что может быть вызвано потенциальными проблемами со
свойствами, самими обучающими данными или процессом выборки данных.
Кроме того, возможен дрейф данных, который со временем может привести
к изменению статистических свойств данных в очередных пакетах. Дрейф
может повлиять на производительность модели, так как модель была обучена
на данных с разными статистическими характеристиками.
• Проверка модели: повторное использование моделей отличается от повтор-
ного использования программного кода. Модели желательно настраивать
для каждого нового сценария. Очень важно провести тщательную проверку
моделей перед их выводом в продакшен-среду. Чтобы убедиться, что модель
эффективно работает на живых данных, важно проверять данные как онлайн,
так и офлайн. Это поможет гарантировать, что прогнозы модели точны и на-
дежны в текущих условиях.
• Отслеживание экспериментов с моделью: все эксперименты, проводимые
с моделями МО, должны тщательно документироваться. Эксперименты в МО
могут включать проверки разных комбинаций кода (в том числе предвари-
тельную обработку, обучение и оценку), датасетов и гиперпараметров. Каждая
уникальная комбинация этих элементов производит метрики, которые не-
обходимо сравнивать с результатами других экспериментов. На основе этого
сравнения строится понимание того, какие решения наиболее эффективны,
и проводится соответствующая оптимизация моделей МО.
524 Глава 13. Архитектура машинного обучения
• Проверка качества кода: каждая спецификация модели МО (обучающий
код, создающий модель МО) должна проходить код-ревью. Проверка каче-
ства кода как начальная точка пайплайна, активируемого пул-реквестом, —
хорошая общая практика.
• Соглашения об именовании: соблюдение стандартных соглашений об име-
новании (таких, как РЕР8 для программирования на Python) в коде МО —
эффективная стратегия решения проблем, вызываемых принципом CAGE
(Changing Anything Changes Everything, то есть «изменение чего-либо изме-
няет все»). Последовательные и четкие соглашения об именовании упрощают
понимание и изменение кода. Они не только помогают поддерживать целост-
ность проекта при внесении изменений, но и позволяют новым участникам
команды быстро разобраться в проекте.
• Мониторинг производительности модели: наряду с метриками проекта
(такими, как среднеквадратичная погрешность), вычисляющими поведе-
ние модели относительно бизнес-целей, важно отслеживать операционные
метрики (задержка, масштабируемость) для предотвращения потерь со
стороны бизнеса.
• Процесс СТ/СМ: в продакшен-среде производительность модели может
снижаться из-за таких факторов, как дрейф данных. Таким образом возникает
необходимость в постоянном развертывании обновлений модели в целях
улучшения или поддержания ее достоверности и точности. Процесс СТ/СМ
играет важную роль в эффективном управлении таким развертыванием. СТ
(continuous training, непрерывное обучение) обеспечивает регулярное обнов-
ление моделей и их обучение на новейших данных, тогда как CM (continuous
monitoring, непрерывный мониторинг) отслеживает эффективность модели
в реальном времени, выявляя любые проблемы или отклонения, которые
могут возникнуть из-за изменения закономерностей в данных. СТ и СМ
вместе образуют надежный фреймворк и обеспечивают долгосрочность
и эффективность моделей МО в продакшен-среде.
• Потребление ресурсов: понимание требований системы на этапах обучения
и развертывания чрезвычайно важно для ее эффективной эксплуатации.
Эта информация поможет команде эффективно оптимизировать ресурсы,
используемые для экспериментов, которые, в свою очередь, могут приве-
сти к значительной экономии затрат. Правильное управление ресурсами
гарантирует, что для имеющихся задач будет выделен необходимый объем
вычислительной мощности, памяти и т. д., не больше и не меньше. Этот
баланс исключительно важен для поддержания производительности и эко-
номичности проектов МО.
MLOps играет важнейшую роль в промышленном применении ИИ. MLOps
объединяет МО, инженерию данных и DevOps для эффективного создания,
развертывания и обслуживания систем МО в условиях реальной эксплуатации.
Глубокое обучение стало основным механизмом решения сложных задач МО.
В следующем разделе оно рассматривается более подробно.
Глубокое обучение 525
Глубокое обучение
Основной задачей МО являются прогнозирование и решение сложных задач
с применением NLP (обработки естественного языка), позволяющие компью-
терам понимать, интерпретировать и генерировать содержательный и полезный
текст на естественном языке. NLP находит много практических применений,
включая машинный перевод, анализ тональности текста, чат-боты и голосовые
помощники, что позволяет организовать более интуитивные и привычные для
человека взаимодействия с машинами. Хотя для обучения с учителем МО тре-
бует заранее определенного набора размеченных данных, глубокое обучение
использует нейросеть для обучения без учителя, чтобы моделировать поведение
человеческого мозга на большом объеме данных, расширяя возможности МО.
Нейросеть представляет собой комплекс алгоритмов, распознающих закономер-
ности в датасетах при помощи процесса, моделирующего работу человеческого
мозга.
При глубоком обучении используется многоуровневая нейросеть, не требующая
предварительной разметки данных. Тем не менее в зависимости от сценария
использования с глубоким обучением можно применять как размеченные, так
и неразмеченные данные. На рис. 13.4 представлена простая модель глубокого
обучения.
На диаграмме показано, что модель глубокого обучения состоит из связанных
узлов; входные слои предоставляют входные данные через различные узлы.
Эти данные проходят через несколько скрытых слоев для вычисления выво-
да и поставляют итоговый вывод модели (инференс) через слой выходных
узлов. Слои входных и выходных узлов считаются видимыми, а обучение
происходит на промежуточных слоях с применением весов и смещений, как
показано на рис. 13.5.
526 Глава 13. Архитектура машинного обучения
Входные
данные
h, =Ф(Хи/,-х,+ь)
м
Рис. 13.5. Модель нейросети глубокого обучения
На этой диаграмме изображена последовательность скрытых слоев, на которых
к связанным узлам применяются весовые функции для изучения закономер-
ности — по аналогии с тем, как это делает человеческий мозг. Как видно из
диаграммы, данные меток поступают на вход и проходят по ребрам нейронной
сети с весами (в примере — 0.2, 0.4, 0.3 и 0.9).
Вес представляет собой параметр нейросети, который влияет на преобразование
входных данных при прохождении через скрытые слои. По сути, вес определяет
степень, в которой заданный ввод повлияет на вывод. Его можно рассматривать
как силу или интенсивность связи между узлами нейросети.
Например, если вес ребра от узла А к узлу В высок, это подразумевает, что
нейрон А имеет более значимое влияние на нейрон В. Веса, близкие к нулю,
указывают на то, что изменение этого конкретного ввода имеет минимальное
влияние на вывод. Отрицательные же веса предполагают обратную связь —
это означает, что увеличение ввода уменьшает вывод, и наоборот. Механизм
весов является фундаментальным для работы нейронных сетей и обучения на
основе данных.
Описанный метод обучения называется прямым распространением, где данные
перемещаются от входного слоя до выходного. Вывод одного слоя передается на
вход следующего слоя и так далее до получения итогового вывода.
Глубокое обучение 527
Существует и другой метод, называемый обратным распространением. В нем
используется вычисление погрешности в прогнозах сети (расхождения между
тем, что прогнозирует сеть, и фактическим результатом). Сеть применяет
алгоритмы для вычисления ошибок прогнозирования, после чего корректирует
свои внутренние параметры — веса и смещения — на основании этой ошибки.
Корректировка выполняется в обратном направлении, начиная с выходного
слоя, поэтому метод и называется «обратным».
Применяя комбинацию прямого и обратного распространения, нейросеть мо-
жет обучаться и совершенствоваться. Она обрабатывает данные (прямое рас-
пространение), выявляет любые неточности в своих предсказаниях (обратное
распространение), а затем изменяет свои параметры для сокращения ошибок.
Этот цикл составляет основу обучения нейросети, в ходе которого она постепенно
становится более эффективной и точной.
Глубокое обучение охватывает разные типы нейросетей, подходящих для разных
видов приложений. Два самых популярных варианта:
• сверточные нейронные сети (CNN, Convolutional Neural Networks): хорошо
справляются с обработкой данных в топологии сети (например, изображений),
что делает их высокоэффективными для задач с визуальным вводом — ком-
пьютерного зрения и задач классификации изображений;
• рекуррентные нейронные сети (RNN, Recurrent Neural Networks): сильной
стороной RNN является обработка последовательных данных, вследствие
чего они идеально подходят для задач, связанных с пониманием языка и речи
(например, NLP и распознавание речи).
К числу самых популярных фреймворков для построения таких моделей ней-
росетей принадлежат Tensor Flow со встроенной поддержкой для разных типов
архитектур нейросетей и MXNet, также поддерживающий диапазон сетевых
архитектур и известный своей эффективностью и масштабируемостью, особенно
в контексте высокопроизводительных приложений глубокого обучения. Кроме
того, заслуживают упоминания такие популярные фреймворки глубокого обу-
чения, как PyTorch, Chainer, Cafe2, ONNX, Keras и Gluon.
В этом разделе приведен общий обзор глубокого обучения. Это очень сложная
тема, и даже для изложения ее основ потребуется целая книга. По каждому из
упомянутых фреймворков также можно найти несколько книг. Тренировка
моделей глубокого обучения требует значительных вычислительных мощно-
стей и может обходиться очень дорого. Тем не менее провайдеры публичных
облачных платформ — такие, как AWS, GCP и Azure — упрощают использование
высокопроизводительных экземпляров на базе GPU для обучения этих моделей
методом оплаты за фактическое использование.
528 Глава 13. Архитектура машинного обучения
Глубокое обучение в реальных условиях
Глубокое обучение чрезвычайно популярно, и существует много сценариев для
его применения в различных отраслях. Рассмотрим несколько примеров.
Здравоохранение: диагностика и профилактика
Модели глубокого обучения помогают специалистам в области здравоохране-
ния, предоставляя второе мнение, а иногда даже выявляя подробности, которые
может упустить человек. Эти модели обучаются на огромных наборах медицин-
ских снимков, учась идентифицировать признаки, связанные с заболеваниями
и симптомами, и могут предсказать вероятность того, что пациент страдает
конкретным заболеванием. Например, Google DeepMind разработал модель
для обнаружения глазных заболеваний на сканах. Анализируя ЗЭ-сканы глаз
пациентов, система глубокого обучения может рекомендовать, каких пациентов
следует направить на лечение.
Беспилотный транспорт: навигация и безопасность
Модели глубокого обучения помогают беспилотным автомобилям понимать
окружение, принимать решения и ориентироваться на местности. Они трени-
руются на обширных датасетах различных сценариев вождения и обучаются
распознавать объекты (например, пешеходов или другие машины), понимать
дорожные знаки и принимать решения по безопасному вождению (когда сле-
дует тормозить или поворачивать). По сути глубокое обучение позволяет этим
машинам интерпретировать и понимать окружающий мир, делая возможным
автоматизированное вождение и повышая уровень безопасности.
Tesla, Waymo и другие компании применяют глубокое обучение в своих бес-
пилотных автомобилях. Эти автомобили оснащены множеством датчиков, по-
ставляющих данные моделям глубокого обучения, что позволяет им принимать
решения в реальном времени.
Производство: контроль качества и прогнозное обслуживание
В производстве модели глубокого обучения оптимизируют эксплуатацию
и улучшают контроль качества. Анализируя данные процессов производства,
модели могут выявлять аномалии или дефекты в продуктах на ранней стадии
цепочки производства, обеспечивая качественный результат. Так, General Electric
применяет глубокое обучение для прогнозного обслуживания оборудования.
Компания использует модели, которые анализируют данные оборудования для
прогнозирования того, когда в нем могут произойти сбои или оно потребует
обслуживания. Таким образом снижается время простоев.
Благодаря своей способности извлекать полезную информацию из огромных,
сложных датасетов, глубокое обучение находит применение в разных областях,
способствуя внедрению инноваций и оптимизации эксплуатации. Глубокое
NLP 529
обучение становится неотъемлемой частью технологических достижений
во множестве отраслей, от здравоохранения, где оно применяется в диагно-
стике, до производства, где оно обеспечивает оптимальность эксплуатации
и качество.
NLP
NLP используется для понимания и чтения естественных языков. Оно объединя-
ет ИИ с вычислительной лингвистикой, чтобы компьютеры могли обрабатывать
естественный язык в виде речи или текста. Рассмотрим некоторые сценарии
практического применения NLP.
Чат-боты и виртуальные помощники
Одно из самых распространенных применений NLP — создание чат-ботов и вир-
туальных помощников (таких, как Siri, Alexa или чат-боты службы поддержки
на различных веб-сайтах).
Чат-боты общаются с пользователями в интерактивном режиме, помогают им
находить информацию, отвечают на вопросы или упрощают проведение опера-
ций. Боты применяют NLP для понимания пользовательского ввода (вопросов
или команд) и генерации содержательных ответов. Анализируя текст, модели
NLP различают смысл сообщений пользователя и реагируют на них соответ-
ствующим образом. Они часто применяются в таких отраслях, как розничная
торговля, банковское дело и служба поддержки, для улучшения взаимодействия
с пользователями и немедленных ответов на их запросы.
Анализ тональности текста
Компании проводят анализ тональности текста (sentiment analysis, или opinion
mining) для оценки отношения к их бренду, продуктам или сервисам, изучая
письменные либо устные высказывания клиентов — например, отзывы и ком-
ментарии в социальных сетях.
Модели анализа тональности, разработанные на базе NLP, исследуют текстовые
данные для определения эмоциональной окраски и классификации эмоций на
положительные, нейтральные или отрицательные. Например, компания может
анализировать отзывы клиентов, чтобы определить, довольны клиенты в целом
или нет. Эта информация очень важна для бизнеса, поскольку на ее основе ком-
пания понимает отношение к себе и может стратегически скорректировать свои
продукты или услуги. Современные решения контактных центров — такие, как
Amazon Connect — произвели революцию в службе поддержки, применяя анализ
общения с клиентами в реальном времени. Такие системы могут анализировать
голосовые взаимодействия для определения эмоций клиентов, что может помочь
представителям службы поддержки во время обработки звонков.
530 Глава 13. Архитектура машинного обучения
Реферирование текста
Автоматизированные инструменты реферирования, генерирующие компактные
аннотации длинных документов или статей, применяют NLP для понимания
и эффективного сжатия контента.
Реферирование текста направлено на сокращение объема текстового документа
без потери критически важной информации и представление его содержимого
в сокращенной форме. Модели NLP извлекают из документов самое важное,
генерируя компактную версию, которая сохраняет суть исходного текста. Рефе-
рирование может быть особенно полезно в таких сферах, как юриспруденция или
научные исследования, где профессионалы должны просматривать огромный
объем документации и оперативно извлекать важную информацию.
Машинный перевод
Сервис Google Translate, способный переводить текст на разные языки, во многом
использует NLP для понимания и точного перевода.
Модели машинного перевода применяют NLP для восприятия текста и его со-
держания на языке оригинала и генерирования эквивалентного текста на языке
перевода. NLP следит за тем, чтобы перевод соответствовал грамматическим
и синтаксическим правилам и сохранял смысл и контекст исходного сообще-
ния. Такой подход разрушает языковые барьеры и упрощает международное
общение и обмен информацией.
Благодаря возможностям понимания и обработки естественных языков NLP
находит многочисленные применения для повышения эффективности обще-
ния, получения аналитической информации и оптимизации процессов в разных
областях, включая службу поддержки, маркетинг и глобальные коммуникации.
Большие языковые модели (LLM, Large Language Models) — такие, как модели
GPT (Generative Pretrained Transformer) — формировались как трансформеры,
демонстрирующие впечатляющую эффективность во многих задачах NLP.
Эти модели проектировались для понимания текстов и генерирования текста,
подобного человеческому, что позволяет им справляться с такими задачами,
как автозавершение, реферирование и перевод. В следующей главе вы больше
узнаете о моделях LLM.
МО и ИИ — необъятные темы, и для более полного их понимания потребуется
прочесть не одну книгу. Мы привели лишь краткий обзор основных моделей,
типов и рабочих процессов МО.
Итоги
В этой главе были рассмотрены фундаментальные концепции и практическое
применение машинного обучения. Теперь вы понимаете основные принципы
МО и его тесную связь с data science, подчеркивающей важнейшую роль данных
Итоги 531
в обучении и оценке моделей МО. Мы исследовали разные типы МО, от обучения
с учителем и без учителя до обучения с подкреплением и глубокого обучения.
Каждый тип сопровождался реальными примерами и распространенными ал-
горитмами, что помогло понять, как и когда они применяются.
Затем были рассмотрены важнейшие концепции переобучения и недостаточного
обучения моделей; особое внимание уделялось тонкому балансу, необходимому
для обобщения моделей. Мы рассмотрели различные стратегии и методы для
эффективного решения этих проблем.
Также были рассмотрены популярные инструменты и фреймворки ИИ, после
чего мы перешли к облачно-ориентированному МО, демонстрирующему пре-
имущества и возможности использования облачных платформ для проектов
МО. Затем была подробно исследована роль данных в МО, с особым внима-
нием к генерации и выбору признаков, а также тщательно проработанному
процессу построения, обучения, настройки, развертывания и управления
моделями МО. Мы рассмотрели принципы проектирования архитектур
МО, уделив внимание лучшим практикам проектирования масштабируемых
и эффективных систем.
Мы разобрали также процесс MLOps как важнейший компонент разработки
проектов МО. Была описана структурированная схема проектирования и реа-
лизации надежных систем МО.
Далее мы перешли к теме глубокого обучения и раскрыли его сильное влияние на
различные отрасли, от распознавания образов до NLP. Была проанализирована
архитектура моделей глубокого обучения и исследованы реальные сценарии
применения МО.
Глава завершилась темами NLP и LLM. Вы узнали, как эти модели изменя-
ют сферы коммуникаций, перевода и генерирования контента. Следующий
шаг — генеративный ИИ — ключевая развивающаяся технология. Глава 14
будет посвящена архитектуре генеративного ИИ, фундаментальным моделям
и существующим решениям, которые помогут накопить опыт в этой области.
ГЛАВА 14
АРХИТЕКТУРА
ГЕНЕРАТИВНОГО ИИ
Технология генеративного ИИ выходит за рамки обычных отраслевых задач —
это продвинутый инструмент, который используется для реформирования
бизнес-операций за счет автоматизации важнейших задач: генерирования
контента, создания изображений и экспертной помощи. Генеративный ИИ
становится революционным шагом вперед в технологиях, вызывая большой
энтузиазм у всех неравнодушных к инновациям. Эта форма технологии,
часто обозначаемая сокращением GenAI (Generative Artificial Intelligence),
выделяется на общем фоне своей выдающейся способностью к независимому
производству нового контента (текста, графики, музыки, видео, программ-
ного кода и т. д.) на уровне, достаточно близком к творческим способностям
человека.
Применение генеративного ИИ расширяется в разных бизнес-областях. Он
может значительно сократить время, ресурсы и средства, необходимые для ве-
дения бизнеса. Например, ChatGPT может помочь с созданием маркетинговых
кампаний или планированием поездок, a Midjourney умеет генерировать изо-
бражения за считаные секунды.
Возможно, вы уже встречались с такими приложениями генеративного ИИ, как
ChatGPT, Midjourney, Gemini (ранее Bard), Amazon Q, Claude.ai и т. д. GenAI
многое узнает из собранной информации, в том числе из интернета, и использует
эти знания для разработки нового контента. Он напоминает умного помощника,
способного генерировать объекты без обращения к человеку за их деталями. Тем
не менее важно понимать, что это не волшебство, а результат большой работы
ума и достижений в области технологии.
Но самое интересное в том, что эти фундаментальные модели могут использо-
ваться для множества разных целей. Например, для генерирования творческого
контента, автоматизации службы поддержки с чат-ботами, повышения качества
анализа данных, предоставления персональных рекомендаций, улучшения пере-
вода на другие языки и даже помощи в исследованиях за счет реферирования
Что такое генеративный ИИ? 533
сложных документов. В этой главе вы больше узнаете о генеративном ИИ,
включая следующие темы.
• Что такое генеративный ИИ?
• Сценарии применения генеративного ИИ.
• Базовая архитектура систем генеративного ИИ.
• Популярные фундаментальные модели генеративного ИИ.
• Как начать работу с генеративным ИИ.
• Эталонная архитектура генеративного ИИ.
• Изменения в реализации генеративного ИИ.
Приготовьтесь к захватывающему путешествию в мир генеративного ИИ. В этой
главе будут раскрыты многие тайны, на которых основаны выдающиеся способ-
ности этой технологии.
Что такое генеративный ИИ?
Генеративный ИИ — искусственный интеллект с выдающимися способностями
к созданию нового контента и генерации идей. Это могут быть диалоги, истории,
графические изображения, видео и даже музыка.
В декабре 2022 года команда ученых из Лаборатории искусственного ин-
теллекта в области дизайна (AiDLab), находящейся в Гонконге, устроила
революционную модную выставку Fashion X AI (https://www.fashionxai.com/
event-highlights-fashionshow). Ее экспозиция был уникальна: все представлен-
ные экспонаты были созданы искусственным интеллектом, который черпал
вдохновение из мудбордов, цветовых палитр и концепций, предоставленных
дизайнерами-людьми.
Как и другие разновидности ИИ, генеративный ИИ работает на базе моделей
машинного обучения. Это довольно обширные модели, которые проходят пред-
варительное обучение на больших объемах данных. Такие модели часто называют
фундаментальными моделями, или ФМ.
Современные ФМ (такие, как OpenAI GPT-4 или Google Gemini для масштаб-
ных языковых задач, Stable Difusion от Stability AI для преобразования текста
в изображения или преобразователь текста в видео OpenAI Sora) могут решать
различные задачи во многих областях. Они могут сочинять посты в соцсетях,
генерировать изображения, решать математические задачи, участвовать в диа-
логах и даже отвечать на вопросы на основании информации в документе. Эти
модели обладают исключительной гибкостью и могут произвести революцию
в создании контента и взаимодействии с ним.
Генеративный ИИ обладает достаточным потенциалом для революционных
изменений в глобальной экономике. По данным Goldman Sachs, за 10 лет гене-
ративный ИИ может привести к 7 %-ому повышению (почти на 7 триллионов
долларов) глобального ВВП и 1,5 %-ому росту производительности труда.
534
Глава 14. Архитектура генеративного ИИ
За дополнительной информацией обращайтесь к отчету Goldman Sachs об
искусственном интеллекте по адресу https://www.goldmansachs.com/intelligence/
artificial-intelligence/.
ФМ выделяются своими размерами и универсальностью, что отделяет их от
традиционных моделей МО, предназначенных для конкретных задач: анализа
тональности, классификации изображений, прогнозирования трендов. В отличие
от этих традиционных моделей, требующих сбора размеченных данных, обуче-
ния и развертывания для каждой задачи, ФМ предлагают более гибкий подход.
Одна предварительно обученная ФМ может быть адаптирована для разных за-
дач. Более того, эти модели можно приспособить для выполнения специальных
функций, уникальных для конкретной отрасли. Очень важно, что подобную
настройку можно произвести с использованием лишь части данных и вычис-
лительных ресурсов, необходимых для обучения модели с нуля.
Успех ФМ обусловлен тремя основными причинами.
• Архитектура трансформера (разновидность нейросети): играет ключевую
роль. Она эффективна, обладает масштабируемостью, может параллелизиро-
ваться и эффективно моделировать отношения входных и выходных данных.
• Контекстное обучение: это революционная парадигма обучения, которая
позволяет снабдить предварительно обученные модели инструкциями для
новых задач или несколькими примерами. Таким образом снимается необхо-
димость в дополнительном обучении на размеченных данных, что позволяет
сразу же применять модели к новым задачам.
• Эмерджентное поведение в масштабе: с увеличением размера модели и на-
боров данных начинают проявляться не выявленные ранее возможности.
Например, большие модели могут генерировать более связный и соответ-
ствующий контексту текст, распознавать сложные закономерности в данных
и даже выполнять такие операции, как распознавание образов и перевод на
другие языки с большей точностью. Они также могут отвечать на вопросы,
требующие многоэтапных рассуждений, предоставлять подробные объяс-
нения и генерировать творческий контент — например, писать музыку или
создавать изображения с пониманием смысловых нюансов. Большие модели
обладают потенциалом для решения задач, которые остаются непосильными
для них, пока модели не достигнут критического размера.
Чтобы вы лучше поняли, как работает генеративный ИИ, рассмотрим некоторые
сценарии его применения.
Сценарии использования генеративного ИИ
Рассмотрим несколько сценариев из разных категорий: взаимодействие с поль-
зователями, производительность сотрудников, эффективность бизнес-операций.
Вы узнаете, как генеративный ИИ расширяет границы существующих ИИ и от-
крывает ряд совершенно новых возможностей.
Сценарии использования генеративного ИИ 535
Преобразование взаимодействий с пользователями
Генеративный ИИ изменяет положение в области взаимодействия клиентов
с бизнесом. Например, вы покупаете обувь в интернете. Виртуальный помощник
на базе генеративного ИИ приветствует вас на сайте интернет-магазина и по-
могает подобрать идеальную пару, соответствующую вашим предпочтениям
в отношении стиля и размера. Он даже покажет вам изображения и ответит на
возникающие вопросы. Ниже приведены другие примеры сценариев, где гене-
ративный ИИ помогает улучшить пользовательский опыт.
• Чат-боты и виртуальные помощники: вы заходите на сайт, и открывается
чат-бот, который предлагает вам помощь. Работа этих чат-ботов обеспечи-
вается генеративным ИИ. Они могут общаться с вами как люди, понимать
ваши вопросы и давать толковые ответы.
• Умные контактные центры: когда вы обращаетесь на горячую линию службы
поддержки, с вами работает генеративный ИИ. Он постарается сделать взаи-
модействие с вами более персонализированным, эффективным и приятным.
Вы получите быстрые и точные ответы на свои вопросы.
• Персонализация: вы замечали, что рекомендации на таких платформах, как
Netflix и Amazon, соответствуют вашим предпочтениям? В их выборе также
участвует генеративный ИИ. Он учится на вашем поведении и адаптирует
свои рекомендации, чтобы они соответствовали вашим вкусам.
• Модерирование контента: генеративный ИИ помогает поддерживать безопас-
ность и порядок в социальных сетях и на других платформах. Он сканирует
контент, генерируемый пользователями (комментарии, посты и т. д.), и про-
веряет, что они соответствуют правилам и рекомендациям.
Повышение производительности труда
Генеративный ИИ не ограничивается клиентскими взаимодействиями: он также
увеличивает производительность труда работников. Представьте, что вы рабо-
таете над проектом и вам нужно подготовить по нему отчет. Чтобы не начинать
с нуля, можно воспользоваться генеративным ИИ для написания вводной части
и перечисления основных пунктов. Такая заготовка станет хорошим началом,
и вы сможете добавлять собственный опыт и аналитическую информацию. Не-
сколько сценариев, в которых генеративный ИИ помогает повысить эффектив-
ность труда работников.
• Интерактивный поиск: когда вам нужна информация, вы пользуетесь поис-
ковой системой. Генеративный ИИ сделает эти системы более разумными.
Вы сможете задавать вопросы на естественном языке, ИИ поймет их и даст
правильные ответы.
• Создание контента: написание статей и отчетов может занимать много вре-
мени. Генеративный ИИ поможет и с этим. Он можете генерировать части
контента (например, сводки или пояснения), которые могут использоваться
для создания хорошо проработанных документов.
536
Глава 14. Архитектура генеративного ИИ
• Реферирование текста: представьте, что вы работаете с длинной исследо-
вательской статьей. Чтобы не читать все страницы подряд, можно поручить
генеративному ИИ составить краткое резюме основных положений. Это
сэкономит время и поможет вам быстрее понять самую важную информацию.
• Создание кода: важнейшая часть работы программистов — написание кода.
Генеративный ИИ может помочь с этим, предлагая фрагменты кода на осно-
вании поставленной задачи. Такая помощь ускоряет кодинг и делает процесс
разработки более плавным.
При интеграции генеративного ИИ в корпоративные сценарии очень важно разо-
браться с юридическими аспектами генерации контента. Вы должны понимать
источник контента, а четкое установление прав собственности необходимо для
предотвращения споров о правах на интеллектуальную собственность. Существу-
ют потенциальные препятствия — например, проблемы нарушения авторского
права и конфиденциальности данных. Чтобы предотвратить эти риски, предпри-
ятие может рассмотреть возможность разработки собственных помощников на
базе генеративного ИИ с использованием проприетарных данных. Такой подход
не только позволит избежать юридических затруднений, но и гарантирует, что
сгенерированный контент будет соответствовать специфическим потребностям
организации и отражать ее ценности.
Оптимизация бизнес-операций
Генеративный ИИ помогает также улучшать различные параметры эксплуата-
ции. На заводе состояние оборудования отслеживается при помощи датчиков.
Генеративный ИИ анализирует данные от этих датчиков и предсказывает,
насколько вероятно возникновение проблем с оборудованием. Это позволяет
планировать техническое обслуживание заранее, предотвращая неожиданные
сбои и прерывания в работе. Ниже перечислены некоторые сценарии, где гене-
ративный ИИ помогает улучшить бизнес-операции.
• Интеллектуальная обработка документов: бизнесу приходится работать
со множеством документов. Генеративный ИИ способен читать и понимать
эти документы, извлекая из них значимую информацию автоматически.
При этом экономится время и снижается риск ошибок. Например, модель
генеративного ИИ может поглощать документы по ипотечному креди-
тованию и отвечать на вопросы о ставке кредита, условиях платежа, сроке
ит. д.
• Прогнозное обслуживание: для компаний, эксплуатирующих оборудование,
очень важно заранее узнать, когда ему понадобится обслуживание. Генератив-
ный ИИ анализирует данные, полученные от машин и систем, и прогнозирует
требования к обслуживанию. Таким образом предотвращаются неожиданные
поломки, а время простоев сводится к минимуму.
• Контроль качества и визуальная проверка: в производстве очень важно сле-
дить, чтобы продукция соответствовала высоким стандартам. Генеративный
Базовая архитектура систем генеративного ИИ 537
ИИ анализирует изображения продукции, выявляя дефекты или расхожде-
ния, которые может упустить человеческий глаз.
• Аугментация (обогащение) данных: обучение ИИ-моделей требует больших
объемов данных. Генеративный ИИ способен создавать синтетические дан-
ные, которые могут использоваться для повышения точности и надежности
таких моделей.
В этом разделе вы узнали о возможных сценариях использования генеративного
ИИ. Пришло время посмотреть, что же происходит за кулисами. Следующий
раздел посвящен архитектуре генеративного ИИ.
Базовая архитектура систем
генеративного ИИ
В системах генеративного ИИ центральное место занимает большая фундамен-
тальная модель. ФМ — крупномасштабные модели, прошедшие предварительное
обучение на огромных датасетах и способные дополнительно настраиваться
или адаптироваться для широкого спектра задач и применений. Чтобы понять
архитектуру генеративного ИИ, разобьем ее на простые компоненты.
• Генератор: основной элемент, который генерирует новые данные — изобра-
жения, текст, музыку или другие формы контента. Генератор узнает законо-
мерности и отношения из существующих данных и использует эти знания
для производства нового, похожего контента. Например, генератор вносит
случайный шум в генерирование изображений и производит изображения,
напоминающие обучающие данные.
• Скрытое пространство: концептуальное пространство, в котором модель
представляет данные в сжатой форме. Это компактное представление данных,
которое используется генератором для создания нового контента; оно пред-
ставляет собой векторное пространство сокращенной размерности. Его можно
сравнить с некой тайной «книгой рецептов», которую использует художник,
чтобы создавать разные типы картин. Например, скрытое пространство может
предоставлять разные варианты авторского стиля при генерировании текста.
При синтезе изображений скрытое пространство может предоставлять такие
признаки, как цвет, текстура и т. д.
• Функция потерь: оценка того, насколько хорошо сгенерированный контент
соответствует желаемому выводу. Функция потерь помогает модели учиться
и совершенствоваться со временем за счет сокращения различий между гене-
рируемыми и реальными данными. Представьте мастера, который объясняет
ученику, насколько его работа близка к идеалу или далека от него. Следуя
этим рекомендациям, ученик обучается и совершенствуется.
• Обучающие данные: существующие данные, на которых обучается модель.
Это могут быть изображения, текст, аудио или любой другой тип доступ-
ного контента. Подобно тому как шеф-повар учится, пробуя разные блюда,
538 Глава 14. Архитектура генеративного ИИ
генератор узнает, что он должен создавать, по примерам. Например, чтобы
сочинять песни, он должен слушать существующие композиции.
Типы генеративных моделей
Прежде чем рассматривать генеративные модели, поговорим о том, чем они от-
личаются от классических дискриминативных моделей МО. Типичная дискри-
минативная модель предназначена для того, чтобы различать классы или кате-
гории данных. В отличие от генеративных моделей, которые создают новые
данные, дискриминативные концентрируются на различии существующих точек
данных на основании их признаков. Эти модели предсказывают вероятность
определенного результата, базируясь на входных данных. Типичные примеры
дискриминативных моделей МО — логистическая регрессия, метод опорных
векторов и т. д. Эта концепция была подробно рассмотрена в главе 13 «Архи-
тектура машинного обучения».
Дискриминативные модели приспособлены для классификации или разметки
текста на основании заранее определенных группировок. Они часто применяются
для таких задач, как распознавание лиц, где их обучение строится на выявлении
конкретных признаков или атрибутов в изображении лица.
Генеративные модели устроены иначе. Как видно из диаграммы, они пыта-
ются понять закономерности и структуру в данных. Они словно изучают не-
известные им правила игры, а затем используют их для создания чего-то, что
Дискриминативные Генеративные
Рис. 14.1. Генеративные
и дискриминативные модели
напоминает исходную игру. В от-
личие от них дискриминативные
модели различают сущности. Они
напоминают детективов, которых
обучили выявлять различия между
объектами. Дискриминативные мо-
дели обычно применяют для задач
обучения с учителем, где целью
является классификация или ре-
грессия, тогда как генеративные
модели применяют там, где нуж-
но понять распределение данных
или сгенерировать новые точки
данных.
Генеративный ИИ охватывает различные модели, создающие новый контент.
Рассмотрим самые популярные из них.
Генеративно-состязательные сети (GAN)
Генеративно-состязательные сети (GAN, Generative Adversarial Networks) со-
стоят из двух компонентов: генератора и дискриминатора. Роль генератора
Базовая архитектура систем генеративного ИИ 539
заключается в производстве контента, а задача дискриминатора — оценка аутен-
тичности контента, проверка его на подлинность. Они вступают в свое рода «со-
стязание», где генератор стремится создать контент, достаточно убедительный,
чтобы «обмануть» дискриминатора. По мере продолжения процесса генератор
последовательно совершенствуется в создании контента, который выглядит все
более реалистично. На рис. 14.2 изображена схема работы модели GAN.
Рис. 14.2. Процесс обучения GAN
На диаграмме представлена базовая структура GAN. Рассмотрим каждый шаг
на примере создания изображений.
• Генератор: этот компонент GAN получает случайный шум на входе. Такой
шум часто называется «скрытой случайной переменной». Роль генератора
заключается в производстве данных, похожих на реальные, на которых он об-
учался. Это как художник в процессе обучения, который изначально создает
случайные наброски на основании некоторых базовых образцов. Например,
генератор начинает с создания случайных изображений, которые должны
напоминать знаменитые картины.
• Реальные данные: подлинные экземпляры данных, для имитации которых
проектировалась сеть GAN. Они служат эталоном качества данных, создавае-
мых генератором. В нашем примере это знаменитые картины из прошлого —
шедевры, которые генератор пытается воспроизвести. Например, картины
таких художников, как Ван Гог или Пикассо, передаются GAN как примеры
настоящего искусства.
• Генерируемые фиктивные данные: генератор использует входной шум для
создания новых точек данных. Предполагается, что эти данные неотличимы
540 Глава 14. Архитектура генеративного ИИ
от реальных, хотя они полностью генерируются моделью. Это новые изобра-
жения, создаваемые генератором, когда он пытается воспроизвести качество
и стиль настоящих картин. Например, генератор производит изображения,
которые имитируют манеру мазка и цветовые палитры работ Ван Гога или
Пикассо.
• Дискриминатор: этот компонент берет как настоящие, так и фиктивные
данные, сгенерированные генератором. Его задача — различить их, по сути
решая, является ли каждый полученный им образец реальным или фиктив-
ным. Дискриминатор можно сравнить с искусствоведом, который изучает
шедевры и сгенерированные изображения, решая, являются новые изобра-
жения подлинными произведениями искусства или имитациями. В нашем
примере дискриминатор проверяет изображения, пытаясь определить, какие
из них являются настоящими картинами Ван Гога или Пикассо, а какие —
подделками.
• Условие: дискриминатор принимает решение о том, являются данные ре-
альными или фиктивными, и предоставляет эту информацию генератору
в виде обратной связи. Искусствовед (дискриминатор) оценивает сгене-
рированные изображения и в виде обратной связи указывает, какие детали
выдают подделку. Например, дискриминатор замечает, что цветовая палитра
сгенерированного изображения не соответствует стилю исходного художника,
и помечает изображение как подделку.
• Корректирующее обучение: на основании оценок дискриминатора гене-
ратор регулирует свои параметры, пытаясь создать более качественные
имитации, которые с большей вероятностью обманут дискриминатора.
Цикл обратной связи продолжается, и дискриминатор также развивает
свою способность отличать реальные данные от имитаций. Этот состя-
зательный процесс продолжается, пока генератор не научится создавать
реалистичные данные. На основании обратной связи обучающийся ху-
дожник (генератор) учится на полученной критике и совершенствует
свои навыки, чтобы создавать более убедительные работы. Например, он
может скорректировать цветовую палитру или стиль мазка, чтобы лучше
воспроизводить стиль шедевров.
Генератор и дискриминатор по сути участвуют в непрерывной игре. Генератор
пытается производить все более реалистичные данные, а дискриминатор стре-
мится усовершенствовать свое умение отличать реальные данные от фиктивных.
Обучение завершается, когда дискриминатор уже не может надежно отличать
фиктивные данные от реальных; это означает, что выходные данные генератора
получаются убедительно реалистичными.
Сети GAN находят практические применения в разных областях; многие по-
пулярные инструменты пользуются этой моделью.
Базовая архитектура систем генеративного ИИ 541
Вариационные автоэнкодеры (VAE)
Представьте огромную кучу деталей Lego разных форм и размеров, которые
нужно компактно упаковать в маленькую коробку. Но есть условие: можно
хранить только инструкции по сборке исходных конструкций, а не сами дета-
ли. Именно так вариационные автоэнкодеры (VAE, Variational AutoEncoders)
работают с данными.
Энкодер — это процесс анализа каждой конструкции Lego и создания кратких
инструкций по ее сборке с меньшим числом деталей. Скрытое пространство — та
самая коробка, где хранятся сжатые инструкции. Декодер — использование этих
инструкций для сборки новой конструкции, похожей на оригинал, из другого
набора деталей. VAE сжимает большие сложные данные (например, изображе-
ния) в компактный код, а затем генерирует новые данные, восстанавливая их
из этого кода.
Этот процесс применяется для таких задач, как создание новых изображений,
музыки или любого цифрового контента, воспроизводящего стиль исходных
данных. На рис. 14.3 изображена схема кодирования и декодирования рисунка
с использованием VAE.
Входные изображения — Энкодер
Кодировки
изображений
— Декодер
Реконструкция изображений
Рис. 14.3. Процесс реконструкции изображений с использованием VAE
На диаграмме изображен процесс реконструкции изображений с использовани-
ем VAE. Ниже приведена краткая схема работы VAE в этой задаче на примере
реконструкции лица человека.
• Входные изображения: исходные изображения, передаваемые системе
VAE. Цель — восстановить эти изображения после кодирования и деко-
дирования. Например, у вас есть набор изображений, где каждое представ-
ляет собой фотографию человеческого лица, качественную и в высоком
разрешении.
• Энкодер в схеме VAE получает входные изображения и сжимает их
в меньшее, более компактное представление, называемое скрытым про-
странством или кодировками изображений. Этот процесс подразумевает
анализ важнейших признаков и закономерностей входных изображений.
Кодировщик анализирует входные фотографии и сжимает каждую из них
в меньший набор чисел, описывающих ключевые признаки лиц: формы
глаз, носа, рта и т. д. Представьте, что вы создаете уникальный код, ко-
торый представляет лицо существенно меньшим объемом данных, чем
в исходном изображении.
542 Глава 14. Архитектура генеративного ИИ
• Кодировки изображений: на этой стадии энкодер преобразует входные
изображения в набор кодировок, представляющих ключевые признаки изо-
бражений в существенно меньшей размерности по сравнению с исходными
изображениями. В контексте VAE эти кодировки также отражают вероят-
ностное распространение входных данных. Эти наборы чисел (кодировки)
отражают самые важные признаки фотографий, хранящиеся в компактной
форме, которую можно рассматривать как подробное описание изображений.
Для фотографий лиц эти признаки могут отражать разнообразие черт лица
разных людей.
• Декодер получает кодировки и пытается восстановить исходные изобра-
жения. Он использует сжатые данные для генерирования изображений, как
можно более близких к исходным входным изображениям. Декодер действует
как художник, которому заказали написать портрет по описанию. Он берет
разные числовые коды и использует их для воссоздания фотографий лиц.
При этом декодер пытается изобразить каждое лицо как можно точнее на
основании только этого компактного кода.
• Реконструированные изображения: итоговый вывод VAE. Это изображения,
которые были реконструированы декодером по их кодировкам. Качество
этих изображений зависит от того, насколько хорошо VAE обучен сжатию
и реконструкции данных. Результат представляет собой серию новых фото-
графий лиц, сгенерированных VAE. Эти реконструированные изображения
должны быть достаточно близки к исходным фотографиям. Положив их ря-
дом с оригиналами, вы увидите, что они очень похожи, хотя восстановленные
изображения могут быть слегка замылены или незначительно отличаться
из-за потери деталей в ходе сжатия.
Фактически процесс описывает способность VAE изучать эффективные пред-
ставления данных и генерировать новые данные, напоминающие исходный
ввод. Процесс используется в разных приложениях, включая шумоподавление
и ретуширование дефектов, а также как генеративная модель для создания новых
изображений, сходных по свойствам с обучающим датасетом.
Генеративные модели на базе
трансформеров
Модели этой категории — такие, как GPT-4 — строятся на базе архитектуры
«трансформер». Сильной стороной этой архитектуры являются понимание
и генерирование последовательностей данных (например, текста). Модель ана-
лизирует закономерности в языке и контексте, что позволяет ей генерировать
связный и релевантный текст.
На рис. 14.4 изображен рабочий процесс модели-трансформера — комплексной
разновидности нейросетей, применяемой в задачах обработки естественных
языков (NLP) — машинном переводе, генерировании текста и т. д. Рассмотрим
каждый этап процесса на примере машинного перевода.
Базовая архитектура систем генеративного ИИ 543
• Слой эмбеддинга (input embedding layer): процесс начинается со слоя, где
отдельные элементы (например, слова в предложении) преобразуются
в числовые векторы, которые могут обрабатываться моделью. Скажем,
модели передается предложение «How are you?», и каждое слово преоб-
разуется в числовой вектор. Можно сказать, что с каждым словом связы-
вается уникальное число-идентификатор, чтобы модель могла понимать
их и работать с ними.
• Позиционное кодирование (positional encoding): позиционное кодирование
добавляется к векторам, чтобы передать модели информацию о позиции
каждого слова в предложении, так как у трансформера нет внутреннего
понимания порядка слов. Например, вместе с числом-идентификатором
каждому слову может присваиваться метка позиции. «How» помечается как
первое слово, «аге» — как второе, «уон» — как третье. Это помогает модели
учитывать порядок слов при обработке.
Рис. 14.4. Компоненты генеративных моделей на базе трансформера
544
Глава 14. Архитектура генеративного ИИ
• Энкодер: объединенный ввод (эмбеддинг и позиционное кодирование) пере-
дается энкодеру. Энкодер обрабатывает входные данные, сохраняя контекст
каждого слова относительно других слов в предложении. Он читает предло-
жение и воспринимает смысл каждого слова в контексте всего предложения.
Энкодер анализирует слова с идентификаторами и позиционными метками,
чтобы понять смысл предложения. Например, он замечает, что «How» в пер-
вой позиции обычно означает вопрос.
• Многопоточный механизм внимания (multi-head self-attention): внутри
энкодера модель назначает разным частям ввода разные веса. Модель слов-
но рассматривает разные параметры значения слова, изучая другие слова,
окружающие его. Энкодер обращает особое внимание на то, как каждое слово
в предложении соотносится с каждым другим. Например, он замечает, что
«How» соединяется с «уон» для формирования вежливого вопроса о благо-
получии собеседника.
• Нейронная сеть с прямой связью (feed-forward network): затем обработан-
ная информация проходит через нейронные сети с прямой связью, которые
дополнительно обрабатывают данные на каждом слое, чтобы уточнить и аб-
страгировать представление. Эти сети уточняют информацию от механизма
внимания — почти как группа редакторов, работающих над черновиком
рукописи, чтобы точнее передать смысл текста.
• Нормализация и остаточные соединения (normalization and residual
connections): они применяются в процессе работы для поддержания потока
данных и снижения риска ошибок преобразования данных на более глубоких
уровнях сети. Эти элементы гарантируют, что информация, проходящая через
модель, не слишком приглушена и усилена. Чтобы предотвратить разрастание
ошибок на уровнях сети, эти компоненты работают как контрольные точки,
которые помогают направлять данные по правильному пути.
• Декодер: после обработки энкодером входные данные поступают к декодеру,
который использует их для генерирования вывода. Он получает обработанные
данные от энкодера и начинает создавать преобразованное предложение —
например, переводить предложение на другой язык или генерировать ответ
в диалоге. Декодер получает обработанную информацию от энкодера и на-
чинает генерировать вывод. Если речь идет о переводе текста, то он начинает
формировать переведенное приложение.
• Выходной слой: итоговый вывод декодера отправляется выходному слою,
который переводит сложный вывод нейросети в удобочитаемый формат —
например, предложение на языке, понятном для человека. На этой стадии
итоговый вывод начинает обретать форму. Если модель переводит предложе-
ние, то этот слой начинает строить перевод на основании всей обработанной
информации.
Модель-трансформер читает и понимает входные данные (предложения,
абзацы и т. д.), обрабатывает их для понимания контекста и генерирует вывод
Базовая архитектура систем генеративного ИИ 545
на основании этого понимания. Для предложения «How are уон?» энкодер
модели обрабатывает вопрос, а декодер генерирует ответ или перевод по
одному слову с учетом как информации от энкодера, так и уже сгенериро-
ванного вывода.
Можно считать, что энкодер проверяет входную информацию, а декодер создает
результат. Например, GPT-4 работает на базе модели-трансформера. Когда вы
даете ему отправную точку, он генерирует осмысленный текст с учетом контек-
ста. Модель использует «внимание» (self-attention) для определения того, какие
слова в начальной точке важны и как они соединяются. Так она может понять,
о чем вы спрашиваете, и дать содержательный ответ.
Другие важные генеративные модели
Кроме уже упомянутых типов, заслуживают внимания следующие генеративные
модели.
• PixelCNN и PixelRNN генерируют изображения пиксель за пикселем, со-
храняя неочевидные детали и зависимости в изображении. Представьте, что
вы рисуете картину пиксель за пикселем, следя за тем, чтобы каждый пиксель
соответствовал окружающим.
• Потоковые модели учатся преобразовывать одно распределение данных
в другое, что позволяет им генерировать данные, соответствующие заданному
распределению. По сути, это рецепт, который превращает простые ингреди-
енты в изысканное блюдо по конкретным инструкциям.
У этих генеративных моделей есть свои сильные стороны и потенциальные
применения, вследствие чего они подходят для широкого спектра задач, от
генерирования изображений до создания текста. Это разнообразие обогащает
спектр возможностей генеративного ИИ.
Важность настройки гиперпараметров и регуляризации
Настройка гиперпараметров и регуляризация — средства настройки и безопас-
ности архитектур генеративных API. Например, при генерировании изображений
можно настраивать такие гиперпараметры, как скорость обучения, определяю-
щая, насколько быстро учится модель; если скорость будет слишком большой,
модель может изучить неправильные закономерности (как человек, который
пытается сыграть мелодию на пианино, но нажимает на клавиши слишком
сильно или слишком слабо). Регуляризация может включать такие приемы, как
исключение (dropout), при котором некоторые нейроны случайным образом
игнорируются в процессе обучения для повышения надежности модели (по
аналогии с тем, как футбольные команды тренируются без некоторых игроков,
чтобы избежать излишней зависимости от одного конкретного игрока). Это
чрезвычайно важно для того, чтобы системы работали хорошо и создавали
высококачественный контент. Оценим степень их важности.
546
Глава 14. Архитектура генеративного ИИ
Настройка гиперпараметров
Гиперпараметры можно рассматривать как рукоятки и переключатели, управля-
ющие процессами обучения систем генеративного ИИ и создания им контента.
Они влияют на такие параметры, как скорость обучения, уровень детализации
результатов и баланс между креативностью и точностью.
Представьте, что вы пытаетесь подобрать идеальную температуру духовки для
выпечки пирога. Слишком жарко — и пирог подгорит; недостаточно жарко —
и он не пропечется. С настройкой гиперпараметров дело обстоит примерно так
же. Она помогает корректировать параметры, чтобы система ИИ обучалась
наилучшим образом, создавая идеальный контент.
Например, гиперпараметры могут управлять длиной мелодий, темпом или
инструментами, используемыми в системе генерирования музыки. Настройка
гиперпараметров обеспечит гармоничное звучание музыки и ее соответствие
заданному стилю.
Регуляризация
Регуляризация напоминает страховочную сетку для канатоходцев. Она не по-
зволяет системе ИИ увлечься и начать создавать слишком экзотический или
нереалистичный контент. Это механизм контроля над выводом, который следит
за тем, чтобы система работала корректно.
В системе генеративного ИИ регуляризация помогает предотвратить пере-
обучение. Напомним, что переобученная система очень хорошо работает на
обучающих данных, но у нее возникают проблемы с новыми, не встречавшимися
ранее данными. Методы регуляризации моделируют включение незначительных
штрафов в отдельные части процесса обучения, чтобы система лучше обобщала
и создавала более разнообразный и креативный контент.
Например, регуляризация в системе генерирования изображений может следить
за тем, чтобы создаваемые изображения содержали согласованные цвета и объ-
екты и не казались слишком зашумленными или странными.
Настройка гиперпараметров и регуляризация играют важную роль в тонкой
настройке производительности систем генеративного ИИ и обеспечивают
создание высококачественного, целостного и реалистичного контента. Без
них система может создавать контент, который будет слишком скучным или
хаотичным и бессмысленным. Подобно тому как шеф-повар регулирует время
готовки и добавляет специи, чтобы получить идеальное блюдо, настройка ги-
перпараметров и регуляризация корректируют систему генеративного ИИ для
создания креативного контента, соответствующего желаемому результату. Они
следят, чтобы система придерживалась правильного пути и создавала интерес-
ный и релевантный контент.
Фундаментальные модели генеративного ИИ 547
Фундаментальные модели генеративного ИИ
Область генеративного ИИ стремительно развивается. Разные организации
расширяют ее границы и запускают мощные фундаментальные модели, про-
кладывая путь для инноваций. Запуск таких моделей, как ChatGPT, придал
очевидное ускорение этой тенденции. Как признанные технологические гиганты,
так и стартапы активно участвуют в революции генеративного ИИ, стремясь
разрабатывать более сложные и функциональные ФМ. Ниже перечислены не-
которые популярные ФМ в области генеративного ИИ.
• Amazon: Amazon Web Services (AWS) — один из ведущих облачных про-
вайдеров с большим набором предложений в области МО и генеративного
ИИ. AWS запустил сервис генеративного ИИ, который называется AWS
Bedrock, с доступом к популярным моделям ФМ, использующим API по
бессерверной схеме. Amazon SageMaker JumpStart — еще одно предложение,
открывающее доступ к широкому диапазону моделей ФМ и способное на-
страивать их по мере необходимости. Amazon Titan — флагманская модель
генеративного ИИ от AWS. Семейство Amazon Titan включает серию ФМ
для разных генеративных задач:
Titan Text Embeddings: для контекстных представлений текста;
Titan Multimodal Embeddings: для интерпретации данных в тексте и гра-
фике;
Titan Text Lite: для эффективной обработки текста в средах с ограничен-
ными ресурсами;
Titan Text Express: для задач быстрой обработки текста;
Titan Image Generator: для создания или изменения визуального контента
по текстовому вводу.
Чтобы больше узнать о ведущих моделях Amazon и быть в курсе инноваций,
посетите страницу Amazon Bedrock: https://aws.amazon.com/bedrock/titan/.
• OpenAI: OpenAI — исследовательская организация, которая занимается
созданием и распространением открытых и этичных ИИ. Она разработала
ряд моделей генеративного ИИ, в числе которых:
DistilGPT2: эффективная модель генерирования текста;
GPT-3: гибкая модель для генерирования текста и ответов на вопросы;
GPT NeoXT: мощная модель для разнообразных языковых задач;
GPT-3.5: эффективный генератор длинных, связных текстов;
GPT-4: мультимодальная модель, приближенная к деятельности человека;
CLIP: анализ отношений между текстом и изображениями;
CLIP-Guided Diffusion: создание изображений по текстовым промтам;
D ALL-E: генерирование изображений по промтам на естественном языке;
MuZero: модель обучается играм, играя сама с собой;
548 Глава 14. Архитектура генеративного ИИ
Text-to-Speech (TTS): преобразование текста в естественно звучащую
речь;
Whisper: модель для преобразования аудио в текст;
Embeddings: преобразование текста в числовые данные;
Moderation: оценка текста на предмет чувствительного содержания;
Sora: генерирование видео по текстовым промтам.
OpenAI работает над GPT-5 — самой свежей на момент написания этой книги
и самой совершенной модели, находящейся в стадии обучения. Дополни-
тельную информацию о моделях OpenAI можно получить на официальном
веб-сайте: https://openai.com/. OpenAI предоставляет подробную информа-
цию о своих моделях, исследованиях, публикациях и доступе к API на своей
платформе.
• Google: компания Google стала первопроходцем в области ИИ и МО. Она
разработала несколько моделей генеративного ИИ, в том числе:
Google Gemini: большая языковая модель для машинного перевода, соз-
дания контента и ответов на вопросы;
BERT: модель, улучшившая понимание контекста в обработке языков;
BigGAN: генерирует реалистичные изображения в высоком разрешении
для создания визуального контента;
Text-to-Text Transfer Transformer (Т5): автоматизирует генерирование
контента для различных задач NLP;
Модели Flan Т-5: адаптированы для специальных задач обработки языков,
включая текст и код;
Pathway Language Model (PaLM): принадлежит к числу больших язы-
ковых моделей, специализируется на генерировании текста и переводах;
LaMDA: модель разработана для диалоговых приложений, имитирует
человеческий стиль общения;
Falcon-7B и Falcon-40B: модели, разработанные для машинного перевода,
ответов на вопросы и генерирования текста;
Chinchilla by DeepMind: большая языковая модель, ориентированная на
задачи генерирования текста и машинного перевода.
В настоящее время Google сосредоточилась на Gemini и строит более со-
вершенную версию модели, расширяя ее моделью подписки. За дополни-
тельной информацией о моделях ИИ и исследованиях компании Google
обращайтесь на веб-сайт Google Al (https://ai.google/) или на сайт DeepMind
(https://deepmind.com/).
• Anthropic: исследовательская организация, которая ставит своей целью
создание общих масштабируемых ИИ, которые соответствуют человеческим
ценностям и предпочтениям. Организация получила значительные инвести-
ции от крупных технологических компаний, включая Amazon (5 миллиардов
долларов) и Google (2 миллиарда). В Anthropic было разработано семейство
Фундаментальные модели генеративного ИИ 549
моделей генеративного ИИ, которое называется Claude и включает следу-
ющие модели:
Claude: ФМ, предлагающая расширенное понимание языков и генера-
тивные способности;
Claude 2: расширенная версия Claude с улучшенными возможностями
обработки языков и понимания контекста;
Claude 2.1: дополнительно улучшенная версия, предлагающая более
точное генерирование и понимание текста;
Claude Instant: модель разрабатывалась с расчетом на скорость. Она
предоставляет быстрые ответы, сохраняя при этом эффективное пони-
мание языка;
Claude 3: новейшее семейство моделей, которое задает новые отраслевые
бенчмарки для различных задач распознавания; существует в трех вари-
антах — Haiku, Sonnet и Opus.
Anthropic предоставляет доступ к этим моделям с разных платформ (таких, как
Amazon Bedrock и Google Vertex AI), помимо их собственного интерфейса веб-
чата Claude AI. За самым последним и полным списком моделей обращайтесь
непосредственно на веб-сайт Anthropic: https://www.anthropic.com/claude.
• Meta (Facebook) AI: Meta AI занимается разработкой и применением ИИ
для различных продуктов и сервисов, связанных с социальными сетями, ком-
муникациями, созданием контента и т. д. Ею были разработаны следующие
модели генеративного ИИ:
RoBERTa: расширенная модель BERT, достигающая лучшей произво-
дительности благодаря расширенному обучению и точной настройке.
DETR: упрощает обнаружение объектов в изображениях, соединяя сверх-
точные нейросети с архитектурой трансформера;
Llama: диапазон языковых моделей, предназначенных для понимания
и генерирования текста; модели доступны в разных размерах для разных
вычислительных потребностей и применений;
BlenderBot: разговорные ИИ, которые могут поддерживать содержатель-
ные и связные взаимодействия, моделирующие диалоги между людьми;
Faiss: библиотека для эффективного поиска и кластеризации, идеально
подходящая для обработки больших датасетов и сложных задач на поиск
сходства.
Информацию о последних достижениях в области генеративного ИИ от Meta
можно найти на веб-сайте https://ai.meta.com/.
• Microsoft: компания Microsoft широко использует предложения OpenAI,
она вложила в их разработку 10 миллиардов долларов и предлагает схему
OpenAI MaaS (Model as a Service, модель как услуга). Она также разработала
такие модели генеративного ИИ, как Turing-NLG и МРТ-7В. В рамках MaaS
компания Microsoft предоставляет модели OpenAI: GPT4, GPT3.5, DALL-E
550 Глава 14. Архитектура генеративного ИИ
и Whisper. Чтобы больше узнать о каталоге моделей Microsoft Azure, посетите
страницу предложений генеративного ИИ https://azure.microsoft.com/en-us/
products/machine-learning/generative-ai.
• AI21 Labs: исследовательская организация, специализирующаяся на по-
нимании и генерировании естественных языков. Она создала несколько
моделей генеративного ИИ, включая DELL (Deep Extension of Latent Logic),
Jurassic-1 и Jurassic-2. AI21 Labs запустила AI21 Studio, чтобы упростить
доступ к своим моделям, а также заключила партнерство с Amazon, чтобы
предоставить доступ к ним через Amazon Bedrock. Информацию о послед-
них предложениях AI21 Labs можно найти в официальном блоге компании
https://www.ai21.com/blog.
• Nvidia: компания Nvidia специализируется на графических процессорах
(GPU), играх, облачных вычислениях, ИИ и многих других направлениях.
Она создала несколько моделей генеративного ИИ, включая StyleGAN2
и GANVerse3D. Вы можете больше узнать о моделях Nvidia на странице
https://www.nvidia.com/en-us/ai-data-science/generative-ai/.
• Jasper.ai: технологическая компания, предоставляющая решения в области
генеративного ИИ для маркетинга. Она разработала модель генеративного
ИИ, которая называется Jasper, а также запустила Jasper Al Copilot для рас-
ширения своих предложений. Дополнительная информация о Jasper доступна
на сайте https://www.jasper.ai/.
• Hugging Face: технологическая компания, предоставляющая инструменты
и платформы с открытым исходным кодом для NLP. В частности, она соз-
дала несколько моделей генеративного ИИ, в числе которых Bloom, BloomZ
176В, Lyra-Fr 10В и Lyra-Mini. Дополнительную информацию о Hugging
Face и ее моделях генеративного ИИ можно найти на официальном сайте
компании, в разделе Model Hub, который содержит подробные описания
и доступ к моделям. Поиск можно начать по ссылке https://huggingface.co/
docs/hub/en/models-the-hub.
Приведенный выше список неполон, но включает наиболее популярные модели.
В области ФМ для генеративного ИИ ведутся серьезные разработки. Можно
ожидать, что с продолжением исследований в ней появятся еще более мощные
и гибкие модели.
Как начать работу с генеративным ИИ
Чтобы начать работу с генеративным ИИ, вам понадобятся инструменты и плат-
формы, подходящие для ваших потребностей. Кем бы вы ни были — рядовым
пользователем, желающим пообщаться с искусственным интеллектом, или
разработчиком/теоретиком МО, собирающимся создавать сложные приложе-
ния, — существует множество ресурсов, которые помогут вам исследовать мир
генеративного ИИ.
Фундаментальные модели генеративного ИИ 551
В следующих подразделах кратко описываются возможные типы пользователей
и даются рекомендации инструментов, с помощью которых они могут начать
свое знакомство с генеративным ИИ.
Конечные пользователи
Рядовые пользователи, желающие применить возможности генеративного ИИ
в своих повседневных занятиях — создании контента, написании электронных
писем, эффективном обучении, — могут воспользоваться следующими инстру-
ментами.
• ChatGPT предоставляет удобного чат-бота на базе GPT-3.5, усовершенство-
ванной языковой модели. Бот генерирует ответы на естественном языке
в зависимости от полученного ввода и может вести беседы на разные темы.
На момент написания книги с ChatGPT можно было работать по адресу
https://chat.openai.com бесплатно, с возможностью обновления до GPT-4
с расширенной функциональностью за ежемесячную подписку стоимостью
$20. Также можно ознакомиться с различными специализированными при-
ложениями из GPT Store от сообщества создателей.
• Claude — модель генеративного ИИ, разработанная в Anthropic. Claude спе-
циализируется на генерировании текста для электронной почты, аннотаций,
историй и т. д. Описание возможностей Claude доступно на странице https://
Claude.ai/chat/; система нацелена на создание контента, соответствующего
человеческим ценностям.
• Google Gemini (ранее Bard) — чат-бот от Google. Как и ChatGPT, Gemini
может давать подробные и неформальные ответы на заданные вопросы и ге-
нерировать разные виды текста: стихи, код, сценарии, электронные письма
и т. д. С его возможностями можно ознакомиться на странице https://gemini.
google.com/app. Gemini можно считать наследником Bard — первого прило-
жения Google, предназначенного для ответов на вопросы.
• Copilot предоставляет сервис генеративного ИИ от компании Microsoft,
использующий такие модели, как GPT-4. Он облегчает ведение диалогов на
естественном языке, упрощая взаимодействие и общение с системами на базе
ИИ. Сервис доступен по адресу https://www.bing.com/chat.
• Amazon Q — сервис от AWS, разработанный для повышения производитель-
ности и лучшего принятия решений в организациях. Это мощный инструмент,
способный быстро предоставлять актуальные ответы на важные вопросы,
помогать с решением задач, генерировать контент и выполнять задачи с ис-
пользованием разнообразной информации, содержащейся в базах данных
компании, коде и корпоративных системах. Дополнительную информацию
об Amazon Q можно найти на странице AWS https://aws.amazon.eom/q/.
• Perplexity AI представляет собой прорыв в технологии поиска и действует
как расширенный чат-бот на базе ИИ, выходящий за рамки традиционных
поисковых систем. Perplexity AI применяет методы МО и NLP, чтобы давать
552 Глава 14. Архитектура генеративного ИИ
точные ответы на широкий спектр вопросов. Он предоставляет пользовате-
лям быстрый доступ к информации по различным темам, упрощая процесс
поиска. Кроме того, он стимулирует пользователей к более глубокому изу-
чению интересующей их темы, задавая уточняющие вопросы или выясняя
дополнительные подробности, что расширяет понимание темы пользователем
и повышает эффективность его обучения. Дополнительную информацию см.
на https://www.perplexity.ai/.
Существует много других приложений ИИ для различных целей от таких ком-
паний, как Jasper, Midjourney, Canva и Luminar. С помощью этих инструментов
генеративного ИИ пользователи могут оптимизировать свои задачи, развивать
креативность и повышать эффективность повседневной работы, от создания
контента до ведения интерактивных диалогов. Все инструменты обладают соб-
ственным набором уникальных возможностей.
Технические специалисты
Разработчики приложений, специалисты по data science, инженеры МО могут
применять генеративный ИИ и тем самым в несколько раз повышать свою
продуктивность, генерируя с его помощью код, уточняя уже разработанные
модели и обращаясь к существующим моделям через API. Рассмотрим эту тему
подробнее.
• Повышение продуктивности за счет генерирования кода: инструменты на
базе генеративного ИИ предоставляют возможность генерирования кода,
чтобы разработчик уделял больше времени бизнес-логике, а не написанию
однообразного вспомогательного кода. Назовем некоторые популярные
инструменты генерирования кода.
Amazon Code Whisperer: AWS предоставляет этот сервис, использующий
NLP и МО для генерирования фрагментов кода на основании запросов
на естественном языке. Например, можно указать Code Whisperer сгене-
рировать функцию Lambda, которая отправляет сообщение электронной
почты с использованием SES, и CodeWhisperer выдаст следующий код:
# Создание функции Lambda, отправляющей сообщение с использованием SES
def lambda_handler(event, context):
client = boto3.client('ses')
response = client.send_email(
Source='XXXXXXXXXXXXXXXXXXXXX',
Destination^
'ToAddresses': [
'XXXXXXXXXXXXXXXXXXXXX',
L
b
Message={
'Subject': {
'Data': 'Hello from SES!',
},
'Body': {
Фундаментальные модели генеративного ИИ 553
'Text': {
'Data': 'Hello from SES!',
ь
},
ь
)
print(response)
return response
CodeWhisperer работает более чем с 1 5 языками программирования, включая
Python, Java и JavaScript, а также популярными интегрированными средами
разработки (IDE), включая VS Code, IntelliJ IDEA, AWS Cloud9 и консоль
AWS Lambda, JupyterLab и Amazon SageMaker Studio. За дополнительной
информацией об Amazon CodeWhisperer обращайтесь по адресу: https://aws.
amazon.com/pm/codewhisperer/.
Azure Copilot: этот инструмент использует OpenAI Codex — большую
языковую модель, обученную на миллиардах строк кода для генерирования
рекомендаций кода в VS Code. Azure Copilot может писать код на многих
языках: Python, JavaScript, TypeScript и др. Пример работы Azure Copilot:
# Представим, что вам нужно написать функцию JavaScript, которая получает
# массив чисел и возвращает среднее.
# Можно начать с ввода имени функции и параметров.
function average(numbers) {
# Затем можно нажать Ctrl+пробел для включения рекомендаций Azure Copilot.
# Azure Copilot предлагает следующий код на основании контекста
# и стандартных схем.
// Инициализировать сумму нулем.
let sum = 0;
// Перебрать массив чисел.
for (let number of numbers) {
// Прибавить число к сумме.
sum += number;
}
// Вычислить среднее, разделив сумму на длину массива.
let average = sum / numbers.length;
// Вернуть среднее.
return average;
}
Интерпретатор ChatGPT: этот инструмент использует ChatGPT — чат-бот
на базе GPT-3 — для интерактивного генерирования кода на основании
ввода на естественном языке. Интерпретатор ChatGPT может использо-
ваться для написания кода на Python, Java и С#. Пример работы интер-
претатора ChatGPT:
Пользователь: Напиши функцию на Python, которая получает список чисел
и возвращает сумму квадратов нечетных чисел.
ChatGPT: def sum_of_squares_of_odd_numbers(numbers):
// Инициализировать sum нулем.
sum = 0
554
Глава 14. Архитектура генеративного ИИ
// Перебрать список чисел.
for number in numbers:
# Проверить число на нечетность,
if number % 2 == 1:
# Возвести число в квадрат и прибавить его к сумме,
sum += number ** 2
# Вернуть сумму.
return sum
Google Codey: Codey поддерживает более 20 языков программирования,
включая такие популярные, как Python, Java, JavaScript и Go. Главная
цель Codey — значительное ускорение цикла разработки. Для этого при-
меняется завершение кода в реальном времени и функциональность гене-
рирования. Разработчики получают в свое распоряжение гибкие средства,
чтобы адаптировать Codey к своему коду и увеличить полезность этого
инструмента на широком спектре проектов.
Если вы планируете пользоваться возможностями ФМ генеративного ИИ в сво-
их приложениях, это легко сделать! Многие из этих моделей доступны через
API, предоставляемые известными облачными платформами и организациями.
Рассмотрим их подробнее.
Использование ФМ генеративного ИИ в приложениях
публичных облачных провайдеров
Интеграция ФМ генеративного ИИ стала более доступной, чем когда-либо,
благодаря широкому спектру облачных платформ, предоставляющих API. Рас-
смотрим некоторые из этих популярных платформ и их возможности.
• AWS открыла доступ к Amazon Bedrock и Agents for Amazon Bedrock в рам-
ках своих усилий по достижению лидерских позиций в облачных ИИ, для
чего AWS предлагает усовершенствованные решения ИИ и формирует
партнерские отношения с ведущими поставщиками ФМ. Amazon Q — новый
помощник на базе ИИ, адаптированный для профессионального применения
и обученный на 17-летнем опыте AWS, — воплощает новаторский подход
AWS к интеграции ИИ в рабочий процесс, повышая эффективность и кре-
ативность в корпоративных средах.
• Amazon Bedrock: надежная облачная платформа, предоставляемая AWS
и разработанная для обучения, создания и развертывания моделей МО.
Amazon Bedrock предоставляет обширное семейство API для различных
задач, включая NLP, распознавание образов и речи. Bedrock предоставляет
доступ к ФМ от Amazon и ведущих организаций в области ИИ — таких, как
AI21 Labs, Anthropic, Cohere, Meta и Stability Al. Чтобы начать разработку
приложений на базе генеративного ИИ с использованием Amazon Bedrock,
необходимо выбрать ФМ, подходящую для ваших целей. Это можно сделать
через Amazon Bedrock Console или API. После выбора модели ФМ ее можно
бесшовно интегрировать в приложение при помощи Amazon Bedrock API.
Фундаментальные модели генеративного ИИ 555
Доступны такие ФМ, как Amazon Titan для обобщения текста, Jurassic-2 для
языковых моделей, действующих по инструкциям, и Claude 3 для ведения
осмысленного диалога и создания контента. Amazon Bedrock можно запустить
по ссылке: https://aws.amazon.com/bedrock/.
• SageMaker Jumpstart: еще одно предложение от AWS, упрощающее разработ-
ку. Инструмент предоставляет готовые модели МО и рабочие процессы для
ускорения запуска проектов МО. SageMaker JumpStart предлагает API для
разных задач — таких, как NLP, компьютерное зрение и распознавание речи.
Чтобы начать работу с приложениями генеративного ИИ через SageMaker
JumpStart, выберите заранее обученную модель, соответствующую требова-
ниям вашего проекта. Выбранную модель можно развернуть в приложении
при помощи SageMaker JumpStart API. Доступны такие модели, как Hugging
Face для NLP, ImageNet для классификации изображений и YOLOv5 для
обнаружения объектов. Чтобы начать работу с SageMaker JumpStart, вос-
пользуйтесь следующей ссылкой: https://docs.aws.amazon.com/sagemaker/latest/
d g/stud i о-j u m psta rt. h tm I.
• Microsoft Azure: Microsoft активно внедряет технологии генеративного ИИ
во всем спектре своих решений, включая Azure, М365, Dynamics 365, Power
Platform, Windows и GitHub, демонстрируя мощь генеративного ИИ в ли-
нейках своих продуктов. У Microsoft есть предложения для корпоративных
клиентов через Azure OpenAI Service, которые отличаются от прямых решений
OpenAI за счет таких функций, как частные сети (private networks), высокий
уровень безопасности, масштабируемость и локализованная доступность
сервиса (региональное присутствие).
• Azure OpenAI: предложение от Microsoft, предоставляющее доступ к раз-
личным фундаментальным моделям для NLP, компьютерного зрения и рас-
познавания речи. Azure OpenAI может использоваться для работы с такими
моделями, как GPT-3 для NLP, DALL-E для генерирования изображений по
текстовым описаниям или Speech Services для задач распознавания и синтеза
речи. Azure AI Studio содержит каталог моделей, сходный с Amazon SageMaker
JumpStart. Компания Microsoft включила в Azure AI схему MaaS с функ-
циональностью, сходной с Amazon Bedrock, и готовыми к использованию
API, средствами точной настройки и инструментами интеграции. На Azure
OpenAI можно подписаться по ссылке https://azure.microsoft.com/en-us/products/
ai-services/openai-service.
• GCP (Google Cloud Platform) интегрировал свою функциональность гене-
ративного ИИ в Vertex AI, демонстрируя стремление расширить свой набор
решений. Краеугольным камнем этой инициативы стала модель PaLM 2,
которая в настоящее время поддерживает более 25 продуктов Google и до-
ступна для клиентов GCP через PaLM API. Компания Google разработала
ряд отраслевых ФМ, включая Med-PaLM для здравоохранения и Sec-PaLM
для безопасности, а также представила подборку ассистентов на базе ИИ,
известную под названием Duet AI в Google Workspace и Google Cloud.
556
Глава 14. Архитектура генеративного ИИ
Значимым расширением семейства ФМ для Google Cloud стала новейшая
фундаментальная модель Gemini. Модель Gemini будет доступна в разных
конфигурациях, включая Ultra, Pro и Nano для широкого спектра при-
ложений. Кроме того, Google Cloud предлагает Model Garden и Generative
AI Studio c Vertex AI, упрощающие работу с внутренними и сторонними
моделями. Несмотря на широкий спектр доступных моделей, в настоящее
время Google Cloud предоставляет прямой доступ только к своим внутрен-
ним моделям PaLM 2 через API для варианта с хостингом; это подчеркивает
стратегию Google по объединению проприетарных технологий с открытыми
инновациями для решений на базе генеративного ИИ. Google Cloud делит
стратегию продукта для Duet AI на два предложения: Duet AI для Google
Workspace и Duet AI для Google Cloud. Duet AI для Google Workspace яв-
ляется прямым конкурентом Microsoft M365 Copilot. Duet AI для Google
Workspace — общедоступный вариант, цена которого на момент написания
книги, как ни удивительно, точно совпадала с ценой М365 Copilot.
• Google Cloud Generative AI предоставляет доступ к мощным, предварительно
обученным генеративным моделям-трансформерам от Google. Google Cloud
Generative API можно использовать для подключения к таким моделям, как
DALL-E 2 для генерирования изображений, Т5 для задач NLP и Big Gan для
генерирования изображений высокого разрешения по простым промтам на
естественном языке. Чтобы начать работать с сервисом Google AI, перейдите
по ссылке https://cloud.google.com/ai/generative-ai.
В табл. 14.1 представлены ФМ от основных облачных провайдеров, доступные
через API (на момент написания книги).
Хотя эти платформы относятся к самым популярным вариантам для раз-
работки приложений генеративного ИИ, сходные возможности предостав-
ляют и другие облачные провайдеры, в том числе IBM Cloud, Alibaba Cloud
и Tencent Cloud.
Выбор оптимальной платформы для проекта зависит от специфических требо-
ваний — нужна ли вам бессерверная среда (Amazon Bedrock), широкий спектр
обученных моделей (SageMaker JumpStart), доступ к моделям OpenAI GPT-3
(Azure OpenAI) или моделям Google LaMDA (Google Cloud Generative AI).
У каждой платформы есть свои преимущества, которые позволяют создавать
приложения генеративного ИИ для разнообразных сценариев использования
и отраслей. Несмотря на доступность многих вариантов ФМ, для успеха при-
ложения очень важно подобрать оптимальную модель. Посмотрим, как выбрать
лучшую ФМ для поставленных целей.
Фундаментальные модели генеративного ИИ 557
Таблица 14-1- ФМ от провайдеров публичных облачных платформ
Провайдеры публичных облачных платформ Доступные поставщики ФМ Доступные ФМ
AWS Amazon Anthropic AI21 Labs Cohere Meta Stability.ai Titan Text Embeddings Titan Multimodel Embed- dings Titan Text Lite Titan Text Express Titan Image Generator Jurassic-2 Ultra Jurassic-2 Mid Claude 2 Claude 2.1 Claude Instant Cohere Command Cohere Command Light Cohere Embed Llama 2 Llama 2 13B Llama 2 70B Stable Difusion XL 1.0
Microsoft Azure OpenAI Models as a Service Meta GPT-4 GPT-4 Turbo, GPT-4 Vision, GPT-3.5 GPT-3.5 Turbo Embeddings models DALL-E Whisper Llama
GCP Google PaLM 2 Imagen Codey Embeddings
558 Глава 14. Архитектура генеративного ИИ
Выбор подходящей ФМ
Выбор подходящей ФМ для проекта является залогом успеха приложения на
основе генеративного ИИ. Вот какие факторы необходимо учитывать при вы-
боре ФМ.
1. Идентификация проблемы: прежде всего четко обозначьте проблему, которую
вы собираетесь решить при помощи генеративного ИИ. Определите, требует
ли ваш проект NLP, компьютерного зрения, распознавания речи или других
задач. Этот первый шаг поможет сократить выбор до ФМ, спроектированных
для конкретной предметной области. Например, вы разрабатываете ассистента
для приложения по поддержке клиентов. Обозначьте проблему как задачу
NLP, ориентированную на взаимодействия в форме чата и звонков. Поищите
ФМ, спроектированные специально для подобных задач NLP.
2. Фактор данных: критически важными факторами выбора являются природа
и объем доступных данных. Некоторые ФМ требуют обширных датасетов для
эффективного обучения, тогда как другие могут хорошо работать с меньши-
ми или специализированными датасетами. Убедитесь, что у вас есть доступ
к соответствующим ресурсам данных для обучения и оценки. Для приложе-
ния-ассистента понадобится доступ к большому набору пользовательских
запросов и ответов. Если датасет большой и разнообразный, рассмотрите
ФМ, которые хорошо работают с такими наборами.
3. Оценка производительности: после определения ФМ, соответствующих
вашей задаче и данным, оцените их производительность на проверочном
датасете. Такая оценка поможет понять, насколько хорошо каждая ФМ под-
ходит к задаче и характеристикам данных. Ищите ФМ, демонстрирующие
хорошие метрики производительности для вашего сценария. Допустим, вы
включили GPT-3, GPT-4 и BERT в список потенциальных ФМ для вашего
приложения. Оцените эффективность каждой ФМ на проверочном датасете,
измеряя такие метрики, как связность ответа, точность и удовлетворенность
пользователя. Выберите ФМ с наивысшими оценками для требований ва-
шего чат-бота. Это гарантирует, что чат-бот будет предоставлять клиентам
полезные и соотносящиеся с контекстом ответы.
4. Настройка: подразумевает обучение ФМ на вашем датасете для повышения
ее производительности и сопоставления с предметной областью задачи.
После настройки модель выдает более точные и актуальные ответы. Пред-
ставим, что вы решили использовать GPT-4 в качестве ФМ, но заметили,
что модели нужно помочь с пониманием профессионального жаргона. Про-
ведите настройку GPT-4 на датасете службы поддержки, чтобы модель лучше
понимала отраслевые термины и фразы. Такая адаптация гарантирует, что
чат-бот будет предоставлять более точные и актуальные ответы и улучшит
взаимодействие с пользователями.
5. Итерации: МО имеет итеративную природу. Приготовьтесь возвращаться
к модели столько раз, сколько потребуется. Возможно, при этом придется
Фундаментальные модели генеративного ИИ 559
уточнять датасет, корректировать гиперпараметры или экспериментировать
с разными ФМ для достижения желаемой производительности. Оптимиза-
ция приложений генеративных API часто требует непрерывного уточнения.
Даже после развертывания приложения-ассистента вы будете получать от
пользователей обратную связь об ответах, которые иногда будут оказы-
ваться неактуальными. Уточняйте датасет, корректируйте гиперпараметры
и решайте проблемы, о которых сообщают пользователи, в итерациях ФМ.
Итеративность помогает поддерживать и повышать эффективность чат-бота
со временем, удовлетворяя потребности пользователей.
6. Промт-инжиниринг: методика, при которой человек создает грамотные
промты для моделей генеративного ИИ (таких, как чат-боты или генераторы
текстов), чтобы тем было проще получить желаемый результат. Метод HITL
(Human-In-The-Loop) исключительно важен, поскольку формулировка
промтов может сильно влиять на ответы ИИ, обеспечивая их адекватность,
точность и соответствие контексту. Он в большой степени отлаживает
взаимодействие с ИИ, настраивая его ответы, чтобы они как можно точнее
соответствовали конкретным задачам или целям.
Следуя этой расширенной схеме, можно эффективно управлять процессом вы-
бора, адаптации и оптимизации подходящей ФМ для проекта генеративного
ИИ с учетом реальных примеров и сценариев использования. Так как ФМ
обучается на очень большом датасете, она может сбиться и давать неточные
ответы. В следующем разделе рассмотрим подробнее, как предотвратить такое
поведение.
Предотвращение галлюцинаций модели
Термином «галлюцинации модели» (в контексте моделей генеративного ИИ)
обозначаются ситуации, когда модель генерирует некорректные, нерелевантные
или вымышленные ответы и/или результаты. Эти ответы обычно выдаются,
когда модель не может понять ввод или когда она выходит за пределы обучаю-
щих данных. Галлюцинации модели могут привести к тому, что пользователь
будет получать недостоверную, бессмысленную или потенциально вредную
информацию. Например, представьте инструмент медицинской диагностики
на базе генеративной модели. Если у модели возникают галлюцинации, она
может давать неверные или неподходящие медицинские рекомендации или
ставить ошибочные диагнозы на основании симптомов пациентов, что может
потенциально представлять опасность для здоровья. Точно так же финансовая
ИИ-модель, используемая для прогнозирования рыночных трендов, может
в результате галлюцинаций выдать неточный прогноз, что приведет к значи-
тельным убыткам пользователей, положившихся на него. Решение проблемы
галлюцинаций модели очень важно для обеспечения достоверности и надеж-
ности И И-систем, особенно в критически важных сферах, где решения могут
иметь серьезные последствия.
560 Глава 14. Архитектура генеративного ИИ
Для предотвращения галлюцинаций модели, а также обеспечения точности
и надежности моделей генеративного ИИ существуют определенные приемы
и стратегии.
• Качество и количество данных: убедитесь, что для модели используются
разнообразные обучающие данные высокого качества, соответствующие
предметной области приложения. Наличие большого и разнообразного
датасета помогает модели понять широкий спектр контекстов и сокращает
риск галлюцинаций. Разнообразный датасет может включать текст из разных
предметных областей, языков и стилей NLP. При обучении чат-бота разно-
образный датасет может помочь модели понять различные пользовательские
запросы и предоставлять ответы, соотносящиеся с контекстом.
• Тонкая настройка, или дообучение (fine-tuning): после исходного обучения
на большом датасете модель настраивается на данных конкретной предметной
области. Дообучение адаптирует модель к конкретной задаче или области
знания, снижая вероятность генерирования галлюцинаторного контента.
Примером служит тонкая настройка предварительно обученной языковой
модели (такой, как Amazon Titan или GPT-4) на медицинской литературе
для создания медицинского чат-бота, который может отвечать на вопросы,
предоставлять информацию и помогать профессиональным медикам понять
сложные медицинские тексты.
• Промт-инжиниринг: создайте четкие и соотносящиеся с контекстом промты
(входящие запросы) при взаимодействии с моделью. Хорошо структури-
рованные промты помогают модели выдавать более точные ответы, соот-
ветствующие ожиданиям пользователя. Вместо туманного «Расскажи мне
о мировой истории» следует создать структурированный промт, например
«Расскажи вкратце о ключевых событиях Второй мировой войны». Генери-
рование образовательного контента будет эффективнее благодаря понятным
и конкретным промтам, обеспечивающим получение точной информации.
• Генерация с аугментированной выборкой (RAG, Retrieval-Augmented
Generation): реализуйте такие методы, как RAG, для получения релевантной
информации из базы знаний или документов и используйте полученный
контекст для генерирования ответов. Такой подход основывает вывод моде-
ли на фактах и информации из определенной области знаний, что снижает
риск галлюцинаций, обеспечивает получение релевантной информации
о продуктах из базы данных и использование этой информации для генери-
рования точных описаний продуктов. Платформы электронной коммерции
могут реализовать RAG для создания подробных и основанных на фактах
описаний продуктов.
• Фильтрация по порогу: установите порог для качества или релевантности
ответа. Принимайте от модели только те ответы, которые соответствуют за-
данному уровню достоверности или релевантности, и отбрасывайте или уточ-
няйте при помощи промтов ответы ниже установленного порога — например,
Фундаментальные модели генеративного ИИ 561
отклонение ответов со степенью уверенности ниже 0,8 обеспечивает их вы-
сокое качество. Чаты поддержки могут использовать фильтрацию по порогу
для предоставления надежных ответов на запросы пользователей.
• Рецензирование человеком: организуйте ревью и модерирование человеком,
чтобы отфильтровать ответы, потенциально содержащие галлюцинации. Ре-
цензенты могут оценивать и исправлять выводы модели для обеспечения точ-
ности и безопасности. Платформы генерирования контента могут нанимать
рецензентов, чтобы обеспечить качество контента и избежать предоставления
неверной информации.
• Непрерывный мониторинг и обратная связь: отслеживайте производитель-
ность модели и собирайте обратную связь от пользователей. Используйте
эту обратную связь для выявления и устранения галлюцинаций модели и ее
улучшения со временем. Собирайте обратную связь от пользователей при
взаимодействиях с чат-ботом и анализируйте ее на предмет возможных усо-
вершенствований. Чат-боты и виртуальные помощники могут непрерывно
развиваться на основании обратной связи, чтобы предоставлять пользова-
телям более качественную поддержку.
• Меры безопасности: реализуйте в модели меры безопасности и ограничения,
чтобы предотвратить генерирование вредоносного, необъективного или не-
подходящего контента; включите в чат-боты фильтры ненормативной лек-
сики для блокирования оскорблений. Интернет-сообщества и социальные
платформы применяют меры безопасности для поддержания уважительной
и дружественной атмосферы.
• Ограничения предметной области: четко определите и сообщите пользова-
телям масштаб и ограничения модели. Это поможет управлять пользователь-
скими ожиданиями и снизит вероятность выдачей моделью галлюцинаторных
ответов на запросы, выходящие за рамки ее компетенции. Например, объ-
ясните пользователям, что погодный чат-бот не может давать медицинские
советы. Особенно полезно определять четкие границы для специализирован-
ных чат-ботов (планировщиков поездок, прогнозов погоды и т. д.).
• Регулярные обновления и обслуживание: поддерживайте актуальность
модели новейшими данными и достижениями в области ИИ. Регулярные об-
новления и обслуживание могут улучшить общую эффективность и сократить
частоту галлюцинаций. Обновите языковую модель новейшими терминами
и языковыми конструкциями. Новостные агентства используют обновленные
языковые модели для генерирования сводок новостей в реальном времени.
Объединяя эти стратегии, разработчики и организации могут свести к минимуму
риск галлюцинаций модели, создавая более надежные и достоверные системы
генеративного ИИ.
Компании развертывают приложения генеративного ИИ во внутренней среде,
прежде чем осуществлять их широкое внешнее развертывание. Такой подход
создает буфер, сокращающий риск поставки ошибочного или неподходящего
562 Глава 14. Архитектура генеративного ИИ
контента. Внутреннее развертывание позволяет организациям уточнять модели
ИИ в контролируемой среде, где последствия ошибок менее серьезны, а ошибки
можно быстро исправить. Сотрудники, знакомые с контекстом и тонкостями
бизнеса, могут предоставить ценную обратную связь по результатам модели,
выявляя любые нерелевантные или неверные ответы, сгенерированные ИИ.
Например, компания может развернуть во внутренней среде чат-бот на базе
ИИ для обслуживания запросов от поддержки IT или HR. Взаимодействуя
с чат-ботом, сотрудники могут сообщать о любых аномалиях или ситуациях,
когда бот предоставляет странные или неточные ответы. Цикл обратной связи
позволяет компаниям проводить настройку модели ИИ, улучшая ее точность
и релевантность, прежде чем развертывать ее в клиентской среде.
Поэтапное развертывание не только снижает риски, связанные с галлюцина-
циями ИИ, но и формирует доверие к технологии — как внутри организации,
так и среди ее клиентов. К тому моменту, когда приложение генеративного ИИ
будет представлено внешним пользователям, оно будет тщательно проверено
и настроено, что обеспечит более надежные и эффективные взаимодействия
с пользователем.
Рассмотрим референсную архитектуру приложения на базе генеративного ИИ.
Референсная архитектура генеративного ИИ
на примере ассистента по ипотечному
кредитованию
Процесс приобретения недвижимости часто пугает потенциальных покупателей,
что отчасти связано с огромным объемом документов, которые им приходится
заполнять. Часто покупатели обнаруживают, что им требуется больше времени,
чтобы разобраться во всех тонкостях. Пытаясь понять важность того, что они
подписывают (особенно в контексте ипотеки), покупатели теряются, чувствуют
себя беспомощными и подавленными. Решение этой проблемы помогает улуч-
шить общее впечатление клиента и выстроить доверительные отношения между
покупателями и банком в процессе подачи заявки и закрытия сделки. Решение
на базе генеративного ИИ способно облегчить бремя покупателя и помочь ему
разобраться в условиях кредитования без помощи отраслевых экспертов или
юристов.
В этом разделе рассматривается архитектура приложения-ассистента по ипотеч-
ному кредитованию. Центральное место в приложении занимает реферирование
(создание краткого резюме) важнейших ипотечных документов. Представлен-
ная архитектура использует бессерверный подход с AWS, а для работы с ФМ
генеративного ИИ в ней используется Amazon Bedrock. Стоит заметить, что эту
архитектуру также можно реализовать на базе другой технологии по вашему
выбору.
Референсная архитектура генеративного ИИ 563
промт = вопрос + шаблон промта + фрагмент kendra
Пользователь
Рис. 14.5. Виртуальный ассистент для ипотечного кредитования,
построенный на базе генеративного ИИ
Amazon Kendra
На архитектурной диаграмме (рис. 14.5) изображено приложение виртуального
ассистента (VA) на базе Amazon Lex — сервиса, предоставляемого AWS для
построения бессерверных чат-ботов. VА имеет интуитивно понятный интер-
фейс, в котором пользователи могут общаться и искать ответы на конкретные
вопросы, относящиеся к их ипотечной документации. Виртуальный ассистент,
использующий понимание и средства обработки естественного языка, интер-
претирует вопросы и промты пользователей, а затем обращается к выдержкам
из отраслевых документов, проиндексированным Amazon Kendra.
Средства интеллектуального поиска Amazon Kendra осуществляют эффективную
выборку релевантных фрагментов документации. Затем эти фрагменты переда-
ются ФМ Amazon Bedrock Claude 2, генерирующей содержательные и связные
ответы на запросы пользователей. Таким образом решение на базе генеративного
ИИ упрощает понимание сложной ипотечной документации. Оно улучшает об-
щие впечатления от покупки недвижимости, предоставляя клиентам надежный
и компетентный источник информации. Это делает процесс более комфортным
для клиента и формирует доверие к кредитной организации.
В решениях на базе генеративного ИИ уделяется особое внимание тому, чтобы
получаемые пользователями ответы строго соответствовали масштабу использу-
емых документов. Для предотвращения возможных галлюцинаций модели или
неточных ответов архитектура использует RAG. Инструментальным аспектом
решения на базе RAG становится интеграция специфической базы знаний или
контента компании в качестве естественной составляющей контекста. База зна-
ний бесшовно интегрируется с пользовательским запросом, образуя подробный
564
Глава 14. Архитектура генеративного ИИ
промт. Консолидированный промт передается ФМ Amazon Bedrock, которая
генерирует точную и краткую сводку на выходе.
Использование возможностей RAG одновременно с интеграцией отрасле-
вых знаний гарантирует, что пользователи будут получать ответы не только
релевантные по контексту, но и в высшей степени точные. Благодаря точ-
ности повышается качество взаимодействия с пользователями и доверие
к приложению на базе генеративного ИИ в процессе подготовки ипотечных
документов.
Решение упрощает контент документов и помогает покупателям быстро получить
необходимую им информацию. Оно не только экономит время, но и позволяет
значительно сократить недопонимания.
Проблемы реализации генеративного ИИ
Реализация генеративного ИИ при всех его выдающихся перспективах так-
же имеет ряд специфических сложностей и факторов, которые необходимо
учитывать. В следующих подразделах рассматриваются некоторые проблемы,
связанные с генеративным ИИ.
Проблема стабильности обучения
Одна из самых значительных проблем, с которыми приходится сталкиваться
при работе с генеративным ИИ, — проблема стабильности обучения. Она может
проявляться в виде проблем сходимости, медленного обучения и даже расхо-
ждения, что затрудняет получение высококачественных генеративных моделей.
В одном из популярных применений генеративного ИИ используется сеть GAN
для создания изображений в высоком разрешении. Проблемы со стабильностью
обучения могут возникнуть в ходе обучения GAN генерированию изображений.
Например, генератор может производить бессмысленные или сильно искажен-
ные изображения. Эти проблемы могут препятствовать сходимости GAN к удо-
влетворительному решению, что обернется плохим качеством генерирования
изображений.
Предотвращение проблемы стабильности обучения в генеративном ИИ требует
комплексного подхода. Такие приемы, как спектральная нормализация (spectral
normalization) и прогрессивное наращивание (progressive growing), могут стаби-
лизировать процессы обучения. Правильная инициализация весов и тщатель-
ное отслеживание кривых потерь помогают предотвратить такие проблемы,
как схлопывание мод распределения (mode collapse) и медленная сходимость
(slow convergence). Кроме того, применение методов пакетной нормализации
и регуляризации может способствовать стабильности обучения. Объединяя эти
стратегии с тонкой настройкой гиперпараметров, разработчики могут улучшить
стабильность моделей генеративного ИИ, обеспечивая более надежную произ-
водительность в разных приложениях.
Проблемы реализации генеративного ИИ 565
Схлопывание мод распределения
Генеративный ИИ достиг значительных успехов в создании контента, похо-
жего на созданный человеком, в различных областях. Тем не менее он может
сталкиваться с такими проблемами, как схлопывание мод распределения (mode
collapse), влияющими на разнообразие и качество результатов. Схлопывание
мод возникает, когда модель генерирует однообразные или повторяющиеся
результаты из-за своей неспособности полностью отражать разнообразие целе-
вого распределения данных. Модель фиксируется на подмножестве возможных
данных, игнорируя более широкий спектр вариаций в датасете.
Если обучать модель генерации, например, новостных статей, схлопывание
может проявляться в том, что модель будет многократного повторять одни и те
же заголовки или содержание вместо создания разнообразных статей. Даже при
наличии обширного датасета модель может выдавать лишь незначительные
вариации одной и той же новости, что резко снижает полезность результата.
Разработчики могут эффективно предотвращать схлопывание мод распределения,
внедряя цели, способствующие разнообразию контента, производя тонкую настрой-
ку гиперпараметров и вводя фактор случайности; таким образом улучшается прак-
тическая ценность и универсальность генеративного ИИ в разных применениях.
Проблемы с интерполяцией скрытого пространства
Интерполяция скрытого пространства — интересное свойство генеративного
ИИ, которое позволяет моделям генерировать промежуточные результаты между
двумя точками скрытого пространства. Тем не менее у нее есть свои проблемы,
связанные с содержательностью и качеством генерируемых результатов. Суть
проблемы с интерполяцией скрытого пространства заключается в том, что гене-
рирование вывода между точками скрытого пространства не всегда порождает
семантически осмысленный и связанный контент. Генерируемые промежуточные
состояния могут требовать большей целостности и релевантности.
Допустим, вы хотите разработать генеративную модель, которая создает изо-
бражения с плавными переходами между разными художественными стилями
(например, изображение переходит от стиля Ван Гога к стилю Пикассо) при
сохранении визуальной целостности. При интерполяции между двумя изо-
бражениями разных стилей полученные переходы могут казаться размытыми,
искаженными или семантически несвязными. Это снижает их предполагаемую
плавность и художественную ценность результата.
Чтобы генеративные модели работали лучше (особенно при создании промежу-
точных результатов), разработчики применяют специальные приемы для повы-
шения эффективности обучения и создания результатов. Рассмотрим их кратко.
• Разделенное обучение представлениям: этот метод помогает модели из-
учать признаки с их четким разделением. Например, если модель обучается
распознаванию лиц, она учится независимо различать такие признаки, как
566
Глава 14. Архитектура генеративного ИИ
возраст, прическа или очки. Это помогает модели генерировать более точные
и реалистичные переходы или изменения.
• Настройка методов интерполяции: процесс интерполяции можно описать
как заполнение пропусков между двумя известными точками. В контексте
генеративных моделей настройка этих методов означает, что шаги (или пере-
ходы) между двумя результатами становятся более плавными и логичными.
Таким образом предотвращаются неожиданные, нереалистичные изменения
при генерировании моделью серии изображений или звуков.
• Использование обучения с частичным привлечением учителя: этот прием
использует в ходе обучения комбинацию размеченных (известных) и нераз-
меченных (неизвестных) данных. Он помогает модели делать более эффек-
тивные предположения о неразмеченных данных благодаря закономерностям,
обнаруженным в размеченных данных. Такой подход может повысить каче-
ство заполнения моделью пропусков или переходов, делая результат более
связным и реалистичным.
При использовании этих методов с генеративной моделью, производящей серию
результатов (например, кадров видео или шагов преобразования), результаты
изменяются плавно и выглядят осмысленно, тем самым повышаются их общее
качество и полезность при решении творческих задач.
Этические соображения и злоупотребления
Вопросы этики и потенциальные злоупотребления технологиями генеративного
ИИ стали важными проблемами современной технологической сферы. Вы-
дающиеся способности ИИ по созданию контента и манипуляций с ним могут
использоваться во вред: для создания дипфейков, распространения ложной
информации или генерирования непристойного контента. Такая деятельность
ведет к возникновению серьезных этических проблем, а также создает угрозы
для доверия и целостности.
Представьте, что генеративный ИИ создает фейковые видеоролики с участием
публичных деятелей, знаменитостей или политиков. Злоумышленники могут
создавать дипфейки, в которых политики делают ложные заявления или соверша-
ют неправомерные поступки. Такие видеоролики могут вводить в заблуждение,
манипулировать общественным мнением или наносить репутационный ущерб.
Учет этических факторов и предотвращение злоупотреблений в генеративном
ИИ исключительно важны для сохранения доверия и честности в цифровую
эпоху. Объединяя строгое модерирование контента, средства аутентификации,
ответственные руководства по использованию ИИ, нормативную базу и просве-
тительскую работу, мы можем защититься от злоупотреблений технологиями
генеративного ИИ. Эти коллективные усилия направлены на то, чтобы генера-
тивный ИИ ответственно и этично работал на пользу общества.
Указанные проблемы подчеркивают сложности при работе с генеративным ИИ.
Для их решения необходимо объединять технические инновации, соображения
Итоги 567
этики и нормативные меры. Кроме того, для решения этих проблем и обеспечения
ответственного и полезного применения генеративных моделей чрезвычайно
важно проводить непрерывные исследования и разработки в сфере ИИ.
Итоги
В этой главе мы погрузились в удивительный мир генеративного ИИ, начав
с подробного объяснения, что же это такое. Мы рассмотрели разнообразные
сценарии, которые стали возможными при использовании генеративного ИИ,
от повышения качества взаимодействия с пользователями до увеличения про-
изводительности сотрудников и оптимизации параметров бизнес-операций.
Чтобы понять базовую архитектуру систем генеративного ИИ, мы выделили
несколько типов генеративных моделей, включая GAN, VAE и модели на базе
трансформеров. Была подчеркнута важность настройки гиперпараметров и ре-
гуляризации в конструировании эффективных архитектур генеративных ИИ.
В контексте ФМ были описаны некоторые популярные ФМ генеративного
ИИ, предоставляемые ключевыми игроками в этой области — Amazon, OpenAI,
Google, Nvidia и другими. Эти модели лежат в основе разработки приложений
на базе генеративного ИИ.
Для читателей, планирующих приступить к работе с генеративным ИИ, были
приведены рекомендации о том, как это лучше сделать, предназначенные для
разных групп пользователей. Конечные пользователи могут исследовать гене-
ративный ИИ при помощи чат-ботов, программисты могут применять их для
генерирования кода, а инженеры-разработчики интегрировать ФМ генератив-
ного ИИ в приложения.
Мы также обсудили такой важный вопрос, как выбор подходящей ФМ, соот-
ветствующей специфическим требованиям проекта и характеристикам данных.
Чтобы поддерживать точность и предотвратить галлюцинации модели, мы рас-
смотрели варианты исходных стратегий работы с генеративным ИИ.
Кроме того, была представлена референсная архитектура ассистента по ипо-
течному кредитованию на базе генеративного ИИ. Ассистент помогает разо-
браться в сложных ипотечных документах, упрощая процедуру приобретения
недвижимости.
Глава завершается описанием проблем с реализацией генеративного ИИ,
включая проблемы стабильности обучения, схлопывания мод распределения,
интерполяции скрытого пространства и этические проблемы, связанные с по-
тенциальными злоупотреблениями.
В этой главе была заложена основа для серьезного изучения генеративного ИИ,
его применения, моделей и проблем; она подготовит вас к дальнейшим иссле-
дованиям и практической реализации решений с применением искусственного
интеллекта.
ГЛАВА 15
ПЕРЕРАБОТКА АРХИТЕКТУРЫ
УНАСЛЕДОВАННЫХ СИСТЕМ
Современные организации работают в непростой среде. Темп изменений оше-
ломляет. Контрольно-надзорные органы устанавливают все новые требования
к отчетности и безопасности, новые технологии меняют ожидания и восприятие
потребителей, а экосистема постоянно развивается с появлением на рынке новых
игроков. В результате организации переопределяют свои бизнес-модели, чтобы
внедрить в них ориентированность на клиента, адаптивность и технологии,
необходимые для привлечения талантов, сохранения конкурентоспособности
и роста.
Модернизация приложений стала важнейшим компонентом новых бизнес-
мод ел ей, требующих быстрого развертывания сред разработки/тестирования,
экспериментов с новыми идеями и разработки новых продуктов и сервисов.
Кроме устранения необходимости вложений в дорогостоящую и громоздкую
инфраструктуру, новая система открывает возможность инноваций в широком
спектре доступных технологий.
Унаследованными (легаси) системами называются приложения, остающиеся
развернутыми в дата-центре десятилетиями без сколько-нибудь значительных
изменений. Эти системы считаются устаревшими, а их обслуживание услож-
няется стремительно изменяющейся технологической средой. Унаследованные
системы определяются возрастом и неспособностью удовлетворять растущие
потребности бизнеса из-за используемой в них архитектуры и технологии.
Часто крупные корпорации используют унаследованные приложения для
решения критически важных повседневных бизнес-задач. Унаследованные
системы широко распространены во многих отраслях: здравоохранении, фи-
нансах, транспорте, производстве, цепочках поставок и т. д. Часто компаниям
приходится тратить значительные суммы на обслуживание и поддержку таких
систем и разбираться в их архитектуре. Переработка архитектуры и модер-
низация унаследованных приложений помогают организациям становиться
более адаптивными, применять инновации и оптимизировать затраты и про-
изводительность.
Проблемы унаследованных систем 569
В этой главе вы узнаете о проблемах с унаследованными приложениями и ме-
тодах переработки их архитектуры. Попытка переписать сложные унаследован-
ные приложения с нуля повышает риск остановок работы бизнеса, поэтому мы
предложим рефакторинг приложений или вариант миграции на более гибкую
инфраструктуру. В этой главе рассматриваются следующие темы.
• Проблемы использования унаследованных систем.
• Определение стратегии модернизации систем.
• Методы модернизации унаследованных систем.
• Определение стратегии облачной миграции для унаследованных систем.
• Миграция с мейнфреймов на публичные облачные платформы.
• Модернизация унаследованного кода генеративным ИИ.
К концу главы вы узнаете о сложностях и драйверах модернизации унаследован-
ных систем. Будут рассмотрены различные стратегии и приемы модернизации.
Поскольку организации все чаще переходят на публичные облачные платформы,
вы также узнаете об облачной миграции унаследованных систем.
Проблемы унаследованных систем
Унаследованные приложения создают значительные проблемы для организа-
ции. С одной стороны, существуют критически важные приложения, которые
использовались организацией в течение многих лет. С другой стороны, унасле-
дованные приложения сдерживают темпы ее модернизации.
В высококонкурентной среде конечные пользователи ищут самые современные,
технологически продвинутые приложения. Вся новая функциональность обычно
появляется с последними версиями ПО, а старые приложения ограничивают
возможность добавления функций, полезных для клиентов.
На рис. 15.1 показаны некоторые важные проблемы, с которыми сталкиваются
организации, использующие унаследованные системы.
Высокие затраты
на обслуживание
и обновление
Отставание от Несовместимость
пользовательских с другими системами
потребностей
Недостаток
квалификации
и документации
Уязвимости в системе
корпоративной
безопасности
Рис. 15.1. Проблемы унаследованной системы
570 Глава 15. Переработка архитектуры унаследованных систем
Прежде чем браться за решение проблемы, важно четко понять ее суть. В следую-
щем разделе проблемы унаследованных систем рассматриваются более подробно.
Отставание от потребностей пользователей
Ориентация на пользователя играет ключевую роль в успехе бизнеса, а от-
ставание от новейших технологических достижений может значительно ему
навредить. Вспомните компанию Nokia, которая когда-то доминировала на гло-
бальном рынке мобильных телефонов. Около десятилетия назад в игру вступили
смартфоны, но Nokia продолжала работать с унаследованной системой, что почти
довело ее до банкротства. Аналогичная история произошла с Kodak — одной
из самых крупных компаний по производству фотоаппаратов. Ей не удалось
выдержать темп внедрения цифровых инноваций, что привело к банкротству
Kodak в 2012 году. Известно множество примеров крупных компаний, которые
прекратили свое существование из-за трудностей с модернизацией унаследо-
ванных технологий и внедрением инноваций.
Пользователи предъявляют весьма высокие требования в современном ланд-
шафте быстро меняющихся технологий и яростной конкуренции. Организациям
приходится меняться с учетом требований пользователей. С развитием техно-
логий пользователь движется вместе с ними и выбирает самые современные
и популярные приложения. Ваши конкуренты могут вырваться вперед, если
они предоставят новую функциональность, необходимую пользователям. Один
из недавних примеров — компания Google, первопроходец в области ИИ/МО,
которая могла бы разработать технологию генеративного ИИ намного раньше.
Однако OpenAI стремительно запустила ChatGPT, опередив Google и заставив
ее наверстывать упущенное. Все это привело к тому, что Google потеряла часть
рынка генеративного ИИ. Эти примеры подчеркивают, насколько важно вне-
дрять новые технологии для поддержания конкурентных преимуществ.
Унаследованные системы также создают проблемы для внутренних корпоратив-
ных приложений. Старые системы, построенные для мейнфреймов, в основном
используют режим командной строки. С другой стороны, сотрудники нового
поколения требуют более удобных средств для выполнения повседневных за-
дач. Возможно, вам понадобится дополнительно убеждать руководство, которое
десятилетиями работало с унаследованными системами и привыкло к ним.
Технология, занимающая важное место в крупных компаниях, должна обнов-
ляться и распространяться на системы, построенные много лет назад. Компании,
у которых основные системы работают на устаревших локальных технологиях,
сталкиваются с серьезными испытаниями, пытаясь обеспечить современный
пользовательский опыт. Многие системы являются результатом множественных
слияний и поглощений, приведших к дроблению хранилищ данных, лишним
затратам на инфраструктуру и замедлению разработки. Все это ведет к неэф-
фективному принятию решений, недостатку адаптивности бизнеса, медленной
отзывчивости на запросы клиентов и высоким затратам на обслуживание. В таких
Проблемы унаследованных систем 571
условиях службе ИТ будет трудно соответствовать требованиям внутренних
стейкхолдеров и внешних клиентов.
Высокие затраты на обслуживание и обновление
Унаследованные системы были созданы давно и работали десятилетиями,
и может показаться, что они требуют меньших затрат. Но со временем общая
стоимость владения оказывается более высокой, так как поддержка и обновление
старых систем обычно обходятся дороже.
Такие обновления часто недоступны в готовом состоянии, и обслуживание
систем требует множества обходных решений. Многие унаследованные систе-
мы плохо совместимы с автоматизацией, что подразумевает больше участия
человека.
Унаследованные системы обычно содержат много проприетарных программ,
что приводит к значительному увеличению лицензионных отчислений. Кроме
того, старое ПО уже не поддерживается поставщиками, а приобретение допол-
нительной поддержки после окончания жизненного цикла может обойтись очень
дорого. С другой стороны, современные системы часто используют технологии
с открытым исходным кодом, которые снижают общие затраты. Простои уна-
следованных систем могут отнимать больше времени и повышать расходы на
эксплуатацию из-за многолетнего технического долга и трудностей с отладкой
кода. Специалистов по обслуживанию унаследованных систем (на таких языках,
как DB2, COBOL, Fortran, Delphi и Perl) трудно найти, они значительно повы-
шают стоимость найма и риск для системы.
Унаследованные приложения работали десятилетиями, и за это время было
внедрено множество изменений, но неиспользуемый код не был удален, что
вызвало значительный технический долг. Любая инициатива по сокращению
технического долга будет рискованной из-за неизвестных последствий и зависи-
мостей. В результате организациям приходится вкладывать средства в ненужный
код и обслуживание системы из опасений нарушить ее работу.
При этом надо иметь в виду, что модернизация унаследованных систем может
обходиться дорого из-за неизвестных зависимостей и возможных простоев.
Принимая решение о модернизации, необходимо провести тщательный анализ
ее экономического эффекта, а также определить окупаемость. Так как стейкхол-
деры обычно хотят видеть немедленный выигрыш от модернизации, получить
средства на ее проведение может быть непросто.
Нехватка квалификации и документации
Унаследованные технологии (в частности, мейнфреймы) содержат множество
сложных компонентов, зависящих друг от друга. Это большие проприетарные
и дорогостоящие серверы, к которым будет трудно получить доступ, если кто-то
захочет независимо развить навыки их использования. Будет трудно получить
572 Глава 15. Переработка архитектуры унаследованных систем
ресурсы на разработку приложения и еще труднее найти людей с опытом работы
со старыми технологиями и операционными системами.
Часто унаследованные системы существуют десятилетиями, и большая часть
тех, кто умеет ими управлять, уже на пенсии. Кроме того, таким системам может
понадобиться документация, в которой отражена многолетняя работа над ними.
Уход старых сотрудников может быть чреват значительной потерей знаний.
Нехватка знаний увеличивает риски при изменении системы из-за неизвестных
зависимостей. Добавление любой, даже незначительной функциональности за-
труднено сложностью системы и нехваткой компетенций.
Новые революционные технологии — расширенная аналитика, МО, гене-
ративный ИИ, 1оТ (интернет вещей) — строятся на новых технологических
платформах. Так как новые технологии плохо интегрируются с устаревшими
системами, организация может проиграть конкуренту, если она не использует
все возможности современных технологий. Современная система формирует
имидж инновационной организации, привлекательной для молодых талантов.
Разработка и обучение еще больше увеличивают расходы на унаследованные
технологии.
Автоматизация часто помогает сократить расходы за счет уменьшения объема
человеческого труда. В современных системах доступны многочисленные ин-
струменты автоматизации (пайплайны DevOps, код-ревью, автоматизированное
тестирование), которые невозможно использовать в унаследованных системах,
что приводит к дополнительным затратам.
Уязвимости в системе корпоративной безопасности
Безопасность входит в число основных приоритетов любой организации или
системы. Унаследованное приложение в старой операционной системе (такой,
как Windows ХР или Windows 2008) создает уязвимости для безопасности
из-за отсутствия поддержки поставщиком. Поставщики программ постоянно
выявляют новые угрозы безопасности и выпускают патчи для закрытия прорех
безопасности в новейших версиях своих продуктов. Любой унаследованный
продукт, о прекращении поддержки которого объявил поставщик, не будет по-
лучать новые патчи безопасности, в результате чего приложение, работающее
в старой версии, сталкивается с различными угрозами.
Проверки работоспособности системы часто игнорируют старые приложения,
и те становятся более уязвимыми для атак. Всего одна уязвимость может при-
вести к тому, что злоумышленники получат доступ к приложению, базе данных
и критически важной информации.
Кроме уязвимостей безопасности, унаследованные приложения сложнее об-
служивать из-за необходимости обеспечивать комплаенс. Так как нормативы
изменяются со временем, для повышения безопасности обработки и использо-
вания данных в унаследованные системы также приходится вносить изменения,
Проблемы унаследованных систем 573
обусловленные требованиями местного законодательства и контрольно-над-
зорных органов.
Например, требования Общего регламента ЕС по защите персональных
данных (GDPR, General Data Protection Regulation) предписывают, чтобы
каждая система предоставляла пользователю возможность запросить уда-
ление его данных. Хотя современные системы могут изначально предостав-
лять эту функциональность на уровне автоматизации и самообслуживания,
в унаследованных системах это требование приходится выполнять вручную
и с большими сложностями.
Обеспечение комплаенса может привести к увеличению расходов на эксплуа-
тацию и времени обслуживания.
Несовместимость с другими системами
Системам приходится взаимодействовать не только с конечными пользователя-
ми, но и с другими системами. Эти системы могут принадлежать другим отделам,
клиентам, партнерам или поставщикам. Разные системы могут обмениваться
данными в стандартном формате, который тоже изменяется со временем. Почти
каждые несколько лет в стандарты форматов файлов и данных вносятся измене-
ния для повышения эффективности обмена данными, и в большинство систем
поэтому тоже приходится вносить изменения. Сопротивление изменениям
и использование старых форматов могут привести к тому, что унаследованная
система окажется несовместимой с новыми и в итоге ею не захотят пользоваться
ни поставщики, ни партнеры. Неспособность обеспечить соответствие требова-
ниям стандартов добавляет существенный бизнес-риск из-за сложных обходных
решений и потери производительности.
Разработка обходного решения для простых требований бизнеса может
усложнить систему. Современные системы строятся на сервис-ориентирован-
ной архитектуре, что упрощает их адаптацию к любым новым требованиям за
счет независимого добавления новых сервисов. Старые системы часто основаны
на монолитной архитектуре, и добавление новой функциональности означает,
что придется перестраивать и заново тестировать всю систему. Современные
архитектуры ориентированы на API, они легко интегрируются с другими систе-
мами для снижения нагрузки. Например, приложение для вызова такси может
использовать Google Maps для навигации GPS (Global Positioning System)
и Facebook или X для аутентификации пользователей. Отсутствие API услож-
няет эти интеграции в унаследованных системах, что приводит к появлению
сложного специально написанного кода.
Унаследованное приложение может столкнуться с проблемами масштабиро-
вания при возрастании нагрузки от зависимой последующей системы. Часто
унаследованные приложения строятся с монолитной архитектурой и зависят от
оборудования. С масштабируемостью в монолитных системах возникают боль-
шие проблемы, так как система не может масштабироваться горизонтально из-за
574 Глава 15. Переработка архитектуры унаследованных систем
привязки к оборудованию, а вертикальное масштабирование ограничивается
максимальной емкостью системы. Кроме того, повышение требований в одной
части монолита требует масштабирования всей системы. Разбиение монолитных
приложений на микросервисы поможет преодолеть проблемы масштабирования
и справиться с нагрузкой.
Помимо обслуживания программного обеспечения, унаследованные приложе-
ния дорого обходятся для аппаратной инфраструктуры, так как они работают
на конкретных версиях. Они распределяются по нескольким базам данных
с дублированием данных и сходной функциональности. Ввиду их монолитной
природы это усложняет консолидацию и использование гибких возможностей
облачных инфраструктур для экономии затрат. Кроме того, децентрализация
систем позволяет командам разработчиков выбирать программные стеки на
основании потребностей отдельных микросервисов и не привязываться к од-
ному технологическому стеку для всей системной функциональности. Можно
применять разные технологии в зависимости от потребностей каждого микро-
сервиса и/или команды, занимающейся его поддержкой.
Рассмотрим теперь некоторые ключевые преимущества модернизации систем.
Определение стратегии модернизации
Часто унаследованные системы выпадают из общей корпоративной стратегии
цифровой трансформации, а проблемы решаются по мере их возникновения.
Такой подход лишает организации возможности провести общую модернизацию
и воспользоваться ее преимуществами.
Если унаследованная система создает серьезные препятствия для бизнеса (на-
пример, в области безопасности или комплаенса) или не может реализовать его
потребности, можно воспользоваться методом «Большого взрыва» — то есть
построить новую систему с нуля и закрыть старую. Это рискованное решение,
но оно решает проблемы бизнес-целей, что невозможно в рамках существующей
унаследованной системы.
В другом возможном решении — поэтапном — модули обновляются по одному,
и старая, и новая системы продолжают работать параллельно. Поэтапное решение
сопряжено с меньшим риском, но занимает больше времени и может обойтись
дороже, так как придется поддерживать обе среды с повышением пропускной
способности сети и инфраструктуры.
Начать следует с анализа портфеля приложений, назначения приоритетов
конкретным приложениям и определения общего плана. При использовании
облачной платформы вы проектируете новую операционную модель, и в вашем
распоряжении оказывается набор инструментов. Можно использовать сторонние
инструменты, чтобы структурировать потребности и предпочтения в выборе
технологий. Или обратиться к консалтинговому партнеру, чтобы завершить
проекты миграции и модернизации быстрее и успешнее.
Определение стратегии модернизации 575
Каждый из этих подходов обеспечит разные преимущества по завершении мо-
дернизации приложения.
Оценка унаследованного приложения
В организации может существовать несколько унаследованных систем, на-
считывающих от десятков тысяч до миллионов строк кода. Модернизация
унаследованной системы должна соответствовать бизнес-стратегии и затратам.
Возможно, какие-то части кода удастся использовать повторно или же придет-
ся переписывать их с нуля, но прежде всего необходимо провести оценку всей
системы и разобраться в ней.
Архитектор решений должен по возможности упростить оценку системы и при-
нять обоснованные решения. Оценка может занять дни и недели в зависимости
от рабочей нагрузки и ее сложности. Области, которым необходимо уделить
основное внимание при проведении оценки.
• Технология: выяснить, какой технологический стек используется в си-
стеме. Если текущая технология устарела и не поддерживается поставщи-
ком, возможно, ее придется заменить. Если доступна более современная
версия технологии, рассмотрите возможность обновления. Часто новые
версии обладают обратной совместимостью при минимуме необходимых
изменений.
• Архитектура: понять общую архитектуру, чтобы сделать ее future-proof
(защищенной от устаревания, адаптивной к будущим изменениям). Воз-
можно, в будущем потребуется незначительно обновить технологию, но
общая архитектура должна быть более монолитной и масштабируемой.
Желательно провести аудит архитектуры в отношении затрат, масштаби-
руемости, доступности, производительности и безопасности. Чтобы при-
вести приложение в соответствие с бизнес-целями, могут потребоваться
значительные архитектурные изменения.
• Оценка кода и зависимостей: унаследованные системы часто содержат сотни
тысяч строк монолитного кода. Запутанные связи между модулями сильно
усложняют систему. Код, который вроде бы не используется в одном модуле,
может повлиять на другие модули, если его неосмотрительно удалить. Эти
строки кода могли быть написаны десятилетия назад и требовали регулярного
рефакторинга и рецензирования. Даже если с технологией и архитектурой
все в порядке, необходимо определить, возможно ли обновление и обслужи-
вание кода. Также необходимо понять, потребуются ли обновления UI для
улучшения пользовательского опыта.
Вы как архитектор решений должны выявить зависимости между разными
модулями и файлами с кодом. Между модулями могут существовать жесткие
связи, и необходимо определить подход для выполнения одновременных
обновлений при модернизации общей архитектуры. В ходе оценки могут
быть обнаружены следующие закономерности.
576 Глава 15. Переработка архитектуры унаследованных систем
Во-первых, многие клиенты понимают, что у них накопилось много ста-
рых приложений, которые плохо соответствуют будущей бизнес-модели;
вероятно, их придется списать. Доля таких приложений может составлять
10-20 %.
Во-вторых, множества поставщиков SaaS еще не существовало 5-7 лет
назад; они могут заменить ряд локальных приложений. Например, многие
клиенты выбирают Salesforce в качестве платформы CRM. Переход на
SaaS сокращает объем операций, которыми управляет команда эксплуа-
тации, — она все еще отвечает за безопасную и надежную эксплуатацию,
но с меньшими операционными издержками.
Затем можно принимать решение о миграции методом lift-and-shift (перенос «как
есть»), а в процессе перемещения — о смене платформы операционной системы,
базы данных или языка для сокращения затрат (например, клиенты желают
перейти с Windows Server на Linux или с Oracle на Postgres для сокращения
стоимости лицензий). Эти методы были рассмотрены в главе 3 «Миграция на
облачные платформы и проектирование облачных архитектур».
Если вы решите провести модернизацию, сосредоточьтесь на модернизации
приложений, которые выделяют ваш бизнес на фоне конкурентов. Давайте рас-
смотрим основные методы модернизации.
Определение метода модернизации
Необходимость модернизации приложения может быть неочевидной для стейк-
холдеров. Постарайтесь выбрать наиболее экономически эффективный метод
и быстрее представить результаты.
На рис. 15.2 показана схема процесса модернизации.
Рис. 15.2. Метод модернизации унаследованных систем
Определение стратегии модернизации 577
После оценки системы необходимо понять схему существующей архитектуры
и ее ограничения. Затем оценить инструменты миграции с учетом технологи-
ческого стека. Например, можно воспользоваться эмулятором для миграции
мейнфрейма или vCenter, если вы переносите приложение в VMWare. Выберите
подходящий метод модернизации и создайте подтверждение концепции (РОС,
Proof of Concept) для выявления пробелов. Ниже перечислены некоторые воз-
можные методы модернизации.
• Модернизация, управляемая архитектурой: этот метод используется для
обеспечения наибольшей адаптивности. Часто архитектурное решение
делается независимым от языка и платформы за счет применения сервис-
ориентированных схем, что обеспечивает команде разработки гибкость
для внедрения инноваций. Вы можете выбрать этот вариант, если оценка
показывает необходимость значительных изменений архитектуры. Начни-
те с реализации самой критической функциональности, а затем создайте
подтверждение концепции (РОС), выявляющее недостатки и необходимые
усилия для их устранения. Используйте микросервисную структуру для
обеспечения масштабируемости и лучшей интеграции с другими системами
в зависимости от унаследованного приложения.
• Переработка системы (реинжиниринг): при таком подходе требуется тща-
тельно разобраться в унаследованной системе и переработать ее в новое
модернизированное приложение. Принимайте технологические решения,
которые помогут создать future-proof систему. Этот подход применяется,
когда унаследованная система слишком сложна и требует долгосрочных
проектов. Начните с модернизации приложения и обновите базу данных по-
следним этапом поэтапного подхода. Необходимо сформировать механизм,
в котором унаследованные и обновленные модули будут сосуществовать
в системе с возможностью гибридных взаимодействий.
• Миграция и усовершенствования: если технология существующей системы
работает относительно хорошо, но ограничивается возможностями суще-
ствующего оборудования и затратами, можно выбрать вариант миграции
с небольшими усовершенствованиями. Например, перенести всю рабочую
нагрузку в облако для улучшения доступности инфраструктуры и опти-
мизации затрат. Кроме того, некоторые готовые инструменты облачных
провайдеров расширены и позволяют чаще вносить изменения и приме-
нять более эффективную автоматизацию. Вариант с миграцией позволяет
модернизировать приложение с меньшими усилиями и делает его future-
proof, то есть адаптируемым к будущим изменениям. Однако возможности
перемещения по схеме lift-and-shift ограниченны, и оно может подходить
не для всех рабочих нагрузок.
Планируя миграцию и модернизацию, учитывайте, какие конкретные области
требуют существенной переработки и модернизации. Модернизация включает
578 Глава 15. Переработка архитектуры унаследованных систем
среды разработчиков в конкретной операционной системе, так как это влияет
на управление патчами. Затем — безопасность, сеть и управление идентифика-
ционными данными. Модернизация этих параметров — отличная возможность
для обеспечения масштабируемости, устойчивости и сокращения затрат. После
этого можно переходить к хранению, резервному копированию и инструментам
баз данных, поскольку все больше приложений перемещается в облако. Кроме
того, необходимо модернизировать инструменты мониторинга и управления,
что требует обучения и переподготовки. Рассмотрим некоторые стратегии мо-
дернизации унаследованных систем.
Преимущества модернизации систем
Создание будущей цифровой стратегии за счет удовлетворения растущей по-
требности в модернизации унаследованных систем имеет немало преимуществ,
как показано на рис. 15.3.
Удовлетворенность клиентов
Рис. 15.3. Преимущества модернизации унаследованных систем
Определение стратегии модернизации 579
Назовем основные преимущества модернизации приложений.
• Удовлетворенность клиентов: использование новейших технологий позво-
ляет предоставить более современный пользовательский интерфейс (UI),
пользовательский опыт (UX) и омниканальные взаимодействия. Потреби-
тели привыкли получать доступ к информации в режиме реального времени
с любого устройства, в любом месте и в любое время. Не нужно создавать
разные варианты UI; интерфейс можно построить один раз и развернуть
на разных устройствах: ноутбуках, планшетах, смартфонах и т. д. Быстрый
и элегантный пользовательский интерфейс улучшает пользовательский опыт
и способствует росту бизнеса.
• Future-proof бизнес-стратегия: модернизация приложения позволяет
действовать более адаптивно и внедрять инновации. Команда может легко
адаптироваться к изменяющимся потребностям и развиваться с новой тех-
нологией.
• Опережение конкурентов: пользователи всегда стремятся к новшествам
и переходят на новые приложения, которые предоставляют более качествен-
ные взаимодействия. Модернизация приложения помогает опережать кон-
курентов за счет внимания к новейшим тенденциям. Например, интеграция
голоса поддерживается многими приложениями, а для повышения безопас-
ности можно использовать распознавание лиц. Это возможно только в том
случае, если приложение использует новейшие технологии.
• Надежность и производительность приложений: каждый новый API и каж-
дая версия операционной системы направлены на повышение произво-
дительности. Использование новейших версий программного обеспечения
и оборудования позволяет повысить производительность, масштабируемость
и доступность. Модернизация приложений способствует сокращению про-
стоев и улучшает безопасность.
• Возможность использования новейших технологий: унаследованные
системы не позволяют получить из данных аналитическую информацию,
которая бы способствовала росту бизнеса. Проведя модернизацию базы
данных и создав озеро данных, можно использовать Big Data и МО для
получения подобной информации. Модернизация также поможет удер-
жать специалистов, которые получат возможность поработать с новыми
технологиями.
• Экономичность: в целом любая модернизация приводит к экономии за счет
сокращения потребности в обслуживании и более естественного обновления.
Применение программ с открытым исходным кодом сокращает затраты на
лицензирование, гибкость оборудования помогает адаптировать облачную
модель оплаты по фактическому использованию, а автоматизация сокращает
количество сотрудников, необходимое для повседневной работы, и повышает
общую эффективность.
580 Глава 15. Переработка архитектуры унаследованных систем
Выполняя миграцию унаследованных базовых систем, организации могут их
модернизировать и сократить затраты на владение, автоматизировать ручные
процессы бэк-офиса, избавиться от старых хранилищ данных, улучшить взаи-
модействие с пользователями и ускорить запуск новых приложений, ориенти-
рованных на рынок.
Модернизация унаследованных систем имеет много преимуществ, но она
может быть очень сложной и требовать значительных усилий. Чтобы выбрать
правильную ее стратегию, необходимо тщательно проанализировать систему.
В следующем разделе рассматриваются методы модернизации унаследованных
систем.
Методы модернизации
унаследованных систем
В зависимости от анализа существующих приложений можно выбрать разные
способы обновления унаследованных систем. Самый простой вариант — ми-
грация и рехостинг — не требует изменения существующей системы. С другой
стороны, простая миграция может не решить долгосрочных проблем или не дать
ощутимые преимущества.
Можно выбрать более сложный путь — такой, как изменение архитектуры или
перепроектирование всего приложения, если система перестает удовлетворять
потребностям бизнеса. На рис. 15.4 представлены последствия выбора разных
методов модернизации.
Инкапсуляция, рехостинг и смена платформы
к_______________________________________________________________>
Рефакторинг и изменение архитектуры
z---------------------------------------------------------------Л
Перепроектирование и замена
Рис. 15.4. Методы модернизации унаследованных систем
Ниже кратко описаны методы модернизации, представленные на этой диаграмме.
Методы модернизации унаследованных систем 581
Инкапсуляция, рехостинг и смена платформы
Инкапсуляция — самый простой подход. Если система критически важна для
ведения бизнеса и должна взаимодействовать с другими приложениями, ра-
ботающими с использованием новейших технологий, используйте этот метод.
Для инкапсуляции необходимо создать API-обертку унаследованной системы,
чтобы другие бизнес-приложения могли с этой системой взаимодействовать.
API-обертка часто используется, когда приложения переносят в облако, но
сохраняют унаследованную версию в локальном дата-центре для модерни-
зации на следующем этапе. Можно выбрать вариант с инкапсуляцией, если
унаследованный код качественный и его легко обслуживать, но еще раз
напомним, что это не даст преимуществ использования новых технологий
и гибкости оборудования.
Рехостинг — одна из прямолинейных стратегий; приложение переносится на
оборудование другого провайдера (например, в облако AWS) без изменений кода.
И снова, как и в случае с инкапсуляцией, рехостинг может сократить затраты
благодаря контракту с провайдером, но не даст преимуществ использования
новых технологий и гибкости оборудования.
Организации часто применяют этот подход, когда им нужно быстро выйти из
существующего контракта. Например, можно начать с перемещения в облако
и провести модернизацию вторым этапом.
Смена платформы может быть более сложной, чем рехостинг, но она даст не-
медленные преимущества. Организации часто выбирают этот подход, если
срок жизни сервера завершается, поддержка отсутствует или для решения про-
блем безопасности требуется обновление системы. Например, если поддержка
Windows Server 2012 завершается, рассмотрите возможность обновления ОС
до версии Windows Server 2022. Необходимо будет переконфигурировать
двоичные файлы для новой операционной системы и провести тестирование,
чтобы убедиться, что все работает нормально, но сильно менять код не придется.
И снова, как и в случае с рехостингом, смена платформы не даст преимущества
новых технологий. С другой стороны, это позволит пользоваться непрерывной
поддержкой поставщика.
Хотя три перечисленных варианта просты, некоторые преимущества обновления
при их выборе останутся недоступными. Рассмотрим еще одно решение, которое
позволит воспользоваться всеми преимуществами модернизации.
Рефакторинг и переработка архитектуры
Рефакторинг — это адаптация кода для новой системы. Общая архитектура
при этом остается неизменной, но код обновляется, чтобы соответствовать
новейшим возможностям языка программирования и версии операционной
системы. Можно провести рефакторинг части кода, чтобы применить автома-
тизацию и расширить функциональность. Если используемая технология все
582 Глава 15. Переработка архитектуры унаследованных систем
еще актуальна и может удовлетворить потребности бизнеса при изменении кода,
выбирайте этот вариант.
Переработка архитектуры подразумевает изменение архитектуры системы
с повторным использованием существующего кода, насколько это возможно. На-
пример, можно создать из монолитной архитектуры архитектуру микросервисов.
Можно брать по одному модулю и преобразовывать его в сервис-ориентирован-
ную архитектуру, назначая каждому модулю эндпоинт RESTful. Переработка
архитектуры позволяет достичь желаемой масштабируемости и надежности; тем
не менее общая производительность может остаться на среднем уровне из-за
использования существующего кода.
Перепроектирование и замена
Решение с перепроектированием — самое сложное, но при этом дающее больше
всего преимуществ. Этот подход можно выбрать в том случае, если унаследо-
ванная система не может обеспечить потребности бизнеса и ее необходимо
обновить. При перепроектировании приходится строить всю систему с нуля,
сохраняя масштаб решения.
На рис. 15.5 представлена схема миграции унаследованной системы на базе
мейнфрейма в облако AWS.
Я Корпоративный дата-центр
операцииооная система________
Унаследованное оборудование
COBOL, PL/I, RPG, С, Assembler
Менеджер
транзакций
Пакетная
подсистема
База данных
Файлы данных
Безопасность! Мониторинг IПланировщик
Модель
приложения
Рис. 15.5. Модернизация унаследованной системы на базе мейнфрейма в облако
Для унаследованной системы на базе мейнфрейма производятся переработка
архитектуры и рефакторинг с перемещением в аналогичные облачные сервисы.
Ориентированность на облако позволяет использовать весь потенциал облачных
сервисов в отношении масштабируемости, производительности, надежности
и затрат. Это повысит адаптивность и инновационность команды за счет вне-
дрения быстро изменяющейся технологии. Стратегии и преимущества облачной
Определение стратегии облачной миграции для унаследованных систем 583
миграции рассматривались в главе 3 «Миграция на облачные платформы и про-
ектирование облачных архитектур».
Перепроектирование унаследованной системы требует долгосрочного про-
екта, подразумевающего значительный объем работы и высокие затраты.
Прежде чем запускать модернизацию, архитектор решений должен тщательно
проверить, не справится ли с потребностями бизнеса какой-либо продукт
SaaS или коммерческий готовый продукт при меньших затратах. Прежде
чем браться за перепроектирование, следует провести сравнительный анализ
экономической эффективности (cost-benefit analysis, СВА) перепроектиро-
вания и покупки.
Иногда выгоднее заменить устаревшую систему новым сторонним продуктом.
Например, в организации сохранилась система CRM десятилетней давности,
которая не может масштабироваться и обеспечивать нужную функциональ-
ность. Как вариант, можно подписаться на продукты SaaS (скажем, Salesforce
CRM) для замещения унаследованной системы. Продукты SaaS основаны на
модели подписки и предлагают лицензирование по схеме «за каждого пользо-
вателя», что может быть приемлемо при небольшом количестве пользователей.
Для огромных корпораций с десятками тысяч пользователей дешевле может
оказаться разработка нового приложения. Проведите анализ экономического
эффекта, чтобы понять окупаемость продуктов SaaS.
Стратегия миграции в облако кратко рассматривается в следующем разделе.
Определение стратегии облачной миграции
для унаследованных систем
С ростом популярности облачных платформ все больше организаций ищет
возможности миграции в облако с целью модернизации унаследованных при-
ложений. Различные методы миграции рассматривались в главе 3 «Миграция
на облачные платформы и проектирование облачных архитектур». Облачная
платформа позволяет масштабировать приложение с низкими затратами, а также
достигать желаемой производительности, высокой доступности, надежности
и безопасности.
Облачные провайдеры — такие, как AWS, Microsoft Azure и GCP — предоставля-
ют различные варианты, которые помогут модернизировать систему. Например,
можно выбрать бессерверную архитектуру микросервисов с использованием
AWS Lambda и Amazon API Gateway и Amazon DynamoDB в качестве бэкенда.
В предыдущем разделе обсуждались методы модернизации унаследованных
систем и их применение при переходе в облако. Блок-схема на рис. 15.6 по-
может решить, стоит ли использовать облачную миграцию для модернизации
унаследованного приложения.
584 Глава 15. Переработка архитектуры унаследованных систем
Рис. 15.6. Путь облачной миграции для модернизации
унаследованных систем
Как видно из диаграммы, если приложение продолжает интенсивно исполь-
зоваться бизнесом и приносит доход, изменения должны быть минимальны.
В этом случае можно провести рефакторинг приложения в облако или сменить
платформу в облаке, если срок службы сервера заканчивается.
Если вы хотите оставить существующие приложения без изменений для под-
держания бизнеса, но при этом полностью перейти на облачную платформу для
сокращения и оптимизации затрат, для перевода унаследованного приложения
в облако выберите вариант lift-and-shift. Если унаследованное приложение
можно заменить, приобретите облачно-ориентированную SaaS-версию про-
дукта и выведите из эксплуатации унаследованное приложение. Возможно, вы
захотите сохранить унаследованную систему в локальном дата-центре, если
она участвует во многих бизнес-зависимостях и ее нельзя переместить в облако
из-за несовместимости.
Проведите анализ суммарной стоимости владения (ТСО, Total Cost of
Ownership), чтобы понять преимущества перехода в облако. ТСО включает
ряд составляющих.
Определение стратегии облачной миграции для унаследованных систем 585
• Затраты на инфраструктуру: сравните затраты на локальную инфраструк-
туру, включая серверы, хранилища, сети и дата-центры, с затратами на об-
лачные сервисы.
• Затраты на обслуживание и администрирование: включите в расчет затра-
ты, связанные с обслуживанием и управлением локальной инфраструктуры
(например, зарплаты IT-персонала), относительно управляемых сервисов
в облаке, сокращающих потребность во внутреннем управлении.
• Масштабирование и гибкость: оцените финансовые последствия от способ-
ности облака масштабировать ресурсы по возрастанию или убыванию в за-
висимости от потребности, что может привести к экономии по сравнению
с фиксированными расходами на локальную инфраструктуру.
• Затраты на лицензирование и подписку: сравните затраты на лицензии ПО
и подписки на облачные сервисы.
• Затраты на миграцию: примите во внимание одноразовые затраты на мигра-
цию рабочих нагрузок в облако, включая затраты на перемещение данных,
оснащение и потенциальное время простоя.
• Безопасность и комплаенс: оцените затраты, связанные с достижением
и поддержанием безопасности и комплаенса — как в локальной, так и в об-
лачной среде.
До начала миграции рекомендуется взять самый сложный модуль унаследо-
ванного приложения и сформировать подтверждение концепции (РОС), чтобы
убедиться, что вся система будет совместимой с облачной платформой. Подроб-
ная формулировка РОС, охватывающая критически важные бизнес-сценарии,
поможет выявить недочеты и значительно сократить риски во время миграции.
При оценке облачной совместимости следует учитывать ряд ключевых фак-
торов. Сначала оцените соответствие архитектуры и убедитесь, что структура
приложения соответствует таким облачным принципам, как масштабируемость,
устойчивость и слабая связанность. Затем выявите любые зависимости от кон-
кретного оборудования или локальных ресурсов, облачная поддержка которых
может быть неоптимальной. Также очень важно, чтобы облачная среда была
способна удовлетворять требования приложения к производительности с уче-
том таких факторов, как сетевая задержка и доступность ресурсов. Кроме того,
убедитесь, что требования к безопасности приложения и комплаенсу полностью
удовлетворяются в облачной среде. Наконец, оцените экономическую эффектив-
ность миграции в облако и убедитесь, что миграция соответствует финансовым
целям организации. Такой комплексный подход помогает определить, насколько
хорошо приложение подходит для облачной среды, и упрощает принятие обо-
снованных решений о миграции.
Документация и поддержка — важнейшие элементы любого обслуживания.
В следующем разделе они рассматриваются более подробно.
586 Глава 15. Переработка архитектуры унаследованных систем
Документация и поддержка
Подготовьте необходимую документацию и мероприятия поддержки для обес-
печения долговременной работоспособности новой системы и корректной ми-
грации на нее. Предоставьте документацию по принятым стандартам кодинга,
чтобы все могли им следовать; это поможет поддерживать актуальность новой
системы. Храните документы, касающиеся архитектуры, как рабочие артефакты,
обновляя их с изменением технологий. Поддержание актуальности системы
поможет избежать повторения ситуации с модернизацией унаследованных
решений.
Подготовьте подробные инструкции по поддержке старых и новых систем.
Старую систему можно оставить на некоторое время, пока новая не будет удо-
влетворять всем бизнес-требованиям и работать как следует. Обновляйте ранбук
по поддержке и следите, чтобы информация не терялась из-за оттока персонала,
а в основе работы с общей базой знаний не лежал человеческий фактор.
Отслеживание зависимостей системы поможет определить влияние любых
будущих изменений. Вы больше узнаете о документации из главы 16 «Докумен-
тирование архитектуры решений». Подготовьте контент для обучения персонала
работе с новой системой и убедитесь, что поддержка системы будет возможна
даже при операционных сбоях.
Мейнфреймы — один из вариантов унаследованных рабочих нагрузок, которые
продолжают работать локально во многих организациях. В следующем разделе
рассматривается их миграция на облачные платформы.
Миграция мейнфреймов на публичные
облачные платформы
Многие предприятия переносят свои рабочие нагрузки на мейнфреймах в облако,
чтобы воспользоваться преимуществами экономичности, повышенной адаптив-
ности, сокращения технического долга, поддержки цифровой трансформации
и аналитики данных, а также чтобы справиться с нехваткой квалифицированных
специалистов по старым мейнфреймам. Миграция мейнфреймовых рабочих
нагрузок проблемнее, чем миграция рабочих нагрузок на базе х86, поскольку
унаследованные приложения для мейнфреймов часто имеют сильную связан-
ность. Например, они могут включать программы, используемые несколькими
подсистемами или напрямую вызываемые другими приложениями. В таких
случаях изменения этих программ повлияют на связанные подсистемы и при-
ложения.
Переход с мейнфрейма в облако открывает уникальную возможность для
будущей работы, хотя облачные провайдеры могут не поддерживать точную
аппаратную архитектуру мейнфрейма. Для организаций такой переход подразу-
мевает стратегические решения: они могут эмулировать среду мейнфрейма на
Миграция мейнфреймов на публичные облачные платформы 587
платформах х86 или же провести рефакторинг приложений для совместимости
с х86. Хотя рефакторинг требует более значительных исходных вложений, он
открывает путь к масштабируемости приложения в облаке, что в итоге соот-
ветствует целям цифровой трансформации и инновационности.
Для унаследованных приложений лучшей практикой является инкрементный
подход, при котором миграция планируется в виде волн. Этот подход помогает
сократить риски, так как приоритеты назначаются тесно связанным приложени-
ям, чтобы они проходили миграцию вместе. Однако иногда он может оказаться
более сложным, поскольку в коде приложений для мейнфреймов может при-
сутствовать связанность во времени (синхронный вызов) или развертывании
(связанные модули).
Рассмотрим некоторые специфические сложности, возникающие при миграции
мейнфреймов.
Проблемы модернизации мейнфреймов
Модернизация мейнфреймов сталкивается с рядом специфических проблем,
вызванных масштабом и сложностью мейнфреймов, а также важностью прило-
жений, которые на них часто выполняются. Такие системы нередко используют
устаревшие языки программирования, содержат неочевидные и недокументиро-
ванные зависимости и требуют особых знаний и навыков, которые встречаются
все реже. Перечислим некоторые из таких проблем.
• Устаревшие языки программирования: мейнфреймы часто используют
унаследованный код, написанный на старых языках, на освоение которых
современному профессионалу потребуется время.
• Сложные системные зависимости: многие приложения для мейнфреймов
десятилетиями развивались и обрастали неочевидными недокументиро-
ванными зависимостями, которые трудно распутать и модернизировать без
нарушения функциональности.
• Необходимость специальных знаний: квалификация, необходимая для
работы с системами на базе мейнфреймов и их обслуживания, встречается
все реже, так как работники с соответствующим опытом выходят на пенсию.
• Целостность и безопасность данных: в процессе модернизации существует
критическая необходимость в поддержании целостности и безопасности
данных, что может быть непросто при переходе из закрытой, безопасной
среды мейнфрейма в более открытую систему.
• Риски для непрерывности операций: мейнфреймы обычно управляют
важнейшими бизнес-операциями. Необходимо тщательно планировать мо-
дернизацию, чтобы не нарушить работоспособность процессов, критически
важных для бизнеса.
• Интеграция с современными технологиями: интеграция приложений для
мейнфреймов с более новыми сервисами и технологиями на базе облака
588 Глава 15. Переработка архитектуры унаследованных систем
может быть затруднена из-за различий в архитектурах и коммуникационных
протоколах.
• Трудности с масштабированием: приложения для мейнфреймов, часто не
рассчитанные на горизонтальное масштабирование, переносятся в совре-
менные облачные среды, в которых эластичное масштабирование является
нормой.
• Высокие расходы: финансовые вложения, необходимые для модернизации,
могут быть довольно значительными, особенно в краткосрочной перспективе.
• Последствия для производительности: производительность модернизиро-
ванных систем должна быть такой же, как у высокооптимизированных систем
на базе мейнфреймов, или выше.
• Сопротивление внутри организации: возможно, вам придется преодолеть
сопротивление внутри организации, так как системы на базе мейнфреймов
глубоко внедрились в повседневную культуру компании и стейкхолдеры,
привыкшие к существующим системам, должны принять изменения.
Обеспечение безопасности и целостности данных при переходе также создает
серьезные проблемы, как и риск нарушения бизнес-процессов, — ведь мейнфрей-
мы обычно обеспечивают выполнение основных бизнес-операций.
Миграция кода приложений с большим количеством связей влияет на зависимые
приложения и создает риски. Чтобы сократить эти риски, необходимо ослабить
связи кода приложения на базе мейнфрейма без последствий для зависимых
приложений. С точки зрения миграции кода можно выделить два основных типа
унаследованных приложений на базе мейнфреймов: автономные приложения
и приложения с совместно используемым кодом. Рассмотрим схемы миграции
для каждого из этих типов более подробно.
Миграция автономных приложений
Допустим, имеются два автономных приложения, А и В, на базе мейнфреймов.
Каждое приложение состоит из программ и подпрограмм, которые оно исполь-
зует монопольно.
Так как приложения автономны, можно сгруппировать их программы и подпро-
граммы COBOL для рефакторинга, как показано на рис. 15.7.
На этой диаграмме программы и подпрограммы на мейнфрейме написаны на
COBOL, и код мигрирует на Java в AWS. Впрочем, эти паттерны ослабления
связей подойдут для любого языка программирования. Миграция выполняется
посредством автоматического рефакторинга унаследованной системы, при кото-
ром код, данные и зависимости автоматически преобразуются на современный
язык, хранилище данных и фреймворк, с гарантиями функциональной эквива-
лентности. Рефакторинг подразумевает использование автоматизированных
инструментов для перевода языка программирования мейнфрейма (такого, как
COBOL) на современный язык (например, Java или .NET).
Миграция мейнфреймов на публичные облачные платформы 589
Рис. 15.7. Модернизация мейнфреймов для автономных приложений
Приложения, прошедшие рефакторинг, развертываются в контейнерах под
управлением AWS Fargate. Fargate — бессерверное вычислительное ядро для
контейнеров, работающее как с Amazon ECS (Elastic Container Service), так
и c Amazon EKS (Elastic Kubernetes Service). В данном случае таблицы базы
данных и файлы с мейнфрейма переносятся с приложением.
После группировки можно провести миграцию приложений А и В в одной или
разных волнах. В любом случае современные компоненты каждого приложения,
полученные в результате рефакторинга, упаковываются и развертываются со-
вместно в среде выполнения. После миграции надо вывести из эксплуатации
локальные приложения на базе мейнфрейма и их компоненты. Рассмотрим
более сложные сценарии, в которых код может использоваться несколькими
приложениями.
Миграция приложений с совместно используемым кодом
Представим, что приложения А и В на базе мейнфреймов запускают общий
код — назовем его программой АВ. Необходимо провести импакт-анализ (оценку
последствий изменений) общей программы АВ, чтобы переносить приложения А,
В и программу АВ вместе. На основании импакт-анализа определяются зависи-
мые приложения, использующие общие программы (такие, как АВ). Необходимо
590 Глава 15. Переработка архитектуры унаследованных систем
провести анализ бизнес-области и установить, можно ли объединить общую
программу в одну область с приложениями, чтобы предоставлять доступ к ней
через API как к одному из сервисов.
Рассмотрим, какие действия можно предпринять для ослабления связей между
приложениями в процессе подготовки к миграции.
Ослабление связей между приложениями с использованием
автономного API
Используя этот способ, можно создать автономный API, преобразовав общую
программу на COBOL в программу Java. Можно применить имеющиеся ин-
струменты автоматизированного рефакторинга, чтобы сгенерировать сетевые
API для программы; тем самым усилия по рефакторингу будут сведены к ми-
нимуму. Этот подход рекомендуется выбирать, когда общая программа может
быть инстанцирована в виде автономного сервиса. Остальные компоненты
приложений А и В переводятся на Java и переносятся в облако. Приложения
можно мигрировать в одной волне, как показано на рис. 15.8.
Рис. 15.8. Миграция приложений с общими программами
с помощью автономных API
Миграция мейнфреймов на публичные облачные платформы 591
При таком подходе необходимо провести рефакторинг обоих приложений
с соответствующими программами и перенести их на облачную платформу.
Используйте отчет об импакт-анализе, чтобы помочь разработчикам и коман-
дам найти приложения, прошедшие рефакторинг, которые вызывают общую
программу АВ. Замените внутренний вызов программы вызовами сетевых API
к общей программе АВ. После миграции выведите из эксплуатации локальные
приложения на мейнфреймах вместе с их компонентами.
Ослабление связей в приложениях с использованием
общей библиотеки
В этом варианте общая программа АВ преобразуется в стандартную библиотеку
Java и упаковывается вместе с приложениями, участвующими в миграции. Ис-
пользуйте этот метод, когда общая программа представляет собой вспомогатель-
ную библиотеку, а не автономный сервис. Остальные компоненты приложений
А и В преобразуются в программы Java и переносятся в облако.
При таком подходе приложения А и В вместе со связанными программами
переводятся на Java и переносятся в облако. Исходный код приложений должен
поддерживаться в полностью управляемом сервисе контроля версий — например,
AWS CodeCommit. Команды, использующие общую программу, могут сотруд-
ничать в отношении изменений кода, через пул-реквесты, ветвление и слияние,
и управлять изменениями, вносимыми в код общей программы. После миграции
выведите из эксплуатации локальные приложения на мейнфреймах вместе с их
компонентами.
Если приложения слишком велики, чтобы их можно было сгруппировать в од-
ной волне миграции, можно провести миграцию за несколько волн, обеспечи-
вая в ее ходе непрерывность сервиса. При таком подходе приложения можно
модернизировать по этапам без группировки. Миграция приложений в разных
волнах ослабляет связи между ними, не требуя значительных изменений кода
на мейнфрейме.
Ослабление связей в приложениях с использованием
очередей сообщений
В этом варианте общая программа АВ преобразуется в программу Java и пере-
носится в облако как часть приложения А. Очередь сообщений используется
как интерфейс между приложением, прошедшим рефакторинг, в облаке и ло-
кальным унаследованным приложением. Этот подход позволяет разбить сильно
связанные приложения на базе мейнфрейма на производители и потребители
и сделать их модульными для независимого функционирования. Дополнительное
преимущество заключается в том, что миграцию приложений можно проводить
в разных волнах.
592 Глава 15. Переработка архитектуры унаследованных систем
Этот подход можно выбрать, когда приложения на мейнфрейме могут взаимо-
действовать с приложениями в облаке, прошедшими миграцию, через оче-
редь сообщений. Желательно убедиться, что архитектурный паттерн очереди
удовлетворяет бизнес-требованиям для приложений на мейнфрейме, поскольку
он подразумевает переработку архитектуры существующих приложений.
Выбирайте решение с очередью сообщений, если для облачной миграции прило-
жений, не входящих в первую волну, требуется много времени (полгода и более).
Если приложения слишком велики для группировки в одну волну миграции,
можно провести их миграцию за несколько волн, как показано на рис. 15.9, и со-
хранить непрерывность сервиса в процессе миграции.
Рис. 15.9. Миграция приложений с общими программами с использованием
очереди сообщений
Как показано на рис. 15.9, процедура миграции состоит из следующих шагов.
1. Миграция (рефакторинг) приложения А вместе с его сопутствующими
программами на облачную платформу; приложение В продолжает работать
в локальной среде.
2. Рефакторинг приложения А (в облаке) для взаимодействия с приложением В
(локального) через очередь сообщений.
3. Рефакторинг приложения В в локальной среде для замены общей програм-
мы программой-посредником, которая отправляет и получает сообщения от
приложения А через очередь сообщений.
4. Вывод из эксплуатации локального приложения А вместе с компонентами
(включая общую программу) после успешной миграции приложения А. При-
ложение В и его компоненты продолжают существовать локально.
Миграция мейнфреймов на публичные облачные платформы 593
5. В следующей серии волн миграции проводится миграция приложения В
и его компонентов. Слабосвязанная архитектура очереди продолжает обес-
печивать взаимодействие между приложениями А и В в облаке. Таким об-
разом сокращаются усилия по рефакторингу приложения В без влияния на
приложение А.
Рекомендуется провести анализ кода, построить карту зависимостей для при-
ложений на мейнфрейме и составить список программ, совместно используемых
приложениями. После этого сгруппировать приложения, использующие одни
и те же программы для одной волны миграции, чтобы сократить количество вы-
зовов программ между локальной и облачной средой. На стадии планирования
проведите импакт-анализ, чтобы определить приложения, использующие общие
программы с приложением, для которого планируется миграция.
В этом разделе в качестве примера для модернизации мейнфреймов использу-
ется платформа AWS. В следующем разделе подробнее рассматриваются пре-
имущества публичных облачных платформ для модернизации мейнфреймов.
Преимущества использования публичной облачной
платформы для модернизации мейнфреймов
Использование публичных облачных платформ для модернизации мейнфрей-
мов имеет целый ряд преимуществ, включая улучшенную масштабируемость,
гибкость и экономичность. Облачная модель оплаты по фактическому исполь-
зованию сокращает капитальные затраты, а расширенная функциональность
упрощает инновации, особенно в таких областях, как ИИ, МО и аналитика.
Облачные среды также предоставляют улучшенные средства восстановления
при сбоях и возможность перепроектировать приложения для большей устой-
чивости и способности адаптироваться к потребностям бизнеса. Рассмотрим
некоторые ключевые преимущества миграции рабочей нагрузки мейнфреймов
на облачные платформы.
• Улучшенная масштабируемость: облачные платформы могут автоматически
регулировать ресурсы для обработки выбросов рабочей нагрузки — в от-
личие от мейнфреймов, требующих ручного масштабирования. Например,
сайт интернет-магазина сможет справиться с пиковым трафиком во время
праздничных распродаж без простоев.
• Экономичность: с облачной моделью оплаты по фактическому использова-
нию компании избавляются от высоких исходных затрат на оборудование
и обслуживание. Например, стартапы могут запускать новые приложения без
вложений в дорогостоящую инфраструктуру на базе мейнфреймов.
• Гибкость и адаптивность: облачные сервисы позволяют компаниям быстро
проводить эксперименты и развертывать новые приложения. Например,
компания может оперативно протестировать новое приложение для под-
держки клиентов на разных рынках без длительного процесса подготовки.
594
Глава 15. Переработка архитектуры унаследованных систем
• Ускорение инноваций: облачные провайдеры предоставляют передовые
инструменты ИИ, МО и аналитики. Компания розничной торговли может
воспользоваться этими инструментами для анализа потребительских данных
и персонализации маркетинговых стратегий, что невозможно на традицион-
ном мейнфрейме.
• Улучшенное восстановление после сбоев: облачные платформы имеют
встроенные решения избыточности и резервного копирования. Например,
финансовая компания может обеспечить непрерывность операций и целост-
ность данных даже при стихийном бедствии.
• Оптимизация ресурсов: облачные платформы позволяют более эффективно
использовать вычислительные ресурсы. Компания может запускать при-
ложения в облаке только в случае необходимости, что сокращает простои
вычислительных ресурсов, типичные для сред мейнфреймов.
• Ускоренный выход на рынок: адаптивность облачных средств сокращает цикл
разработки. Компания-разработчик мобильных приложений может быстро
развертывать и обновлять приложения, оставаясь впереди конкурентов.
• Глобальный охват: облачные сервисы с дата-центрами по всему миру по-
зволяют компаниям развертывать приложения рядом с пользователями.
Например, стриминговый сервис с их помощью может предоставлять контент
с низкой задержкой пользователям со всего мира.
• Улучшенные средства безопасности: крупные облачные провайдеры вкла-
дывают значительные средства в кибербезопасность. Это означает, что не-
большая компания может пользоваться теми же преимуществами средств
безопасности, что и крупные корпорации, чего достаточно трудно достичь
с локальными мейнфреймами.
• Упрощение интеграции с современными технологиями: облачные технологии
упрощают интеграцию с современными приложениями и сервисами. Напри-
мер, медицинская организация может интегрировать облачные инструменты
диагностики на базе ИИ со своей системой управления пациентами — в среде
мейнфрейма это было бы слишком сложно и ресурсоемко.
AWS предоставляет платформу М2 (Mainframe Modernization), предназначенную
для миграции и модернизации локальных приложений на базе мейнфреймов
в облачно-ориентированную, полностью управляемую среду выполнения в AWS.
Перечислим основные преимущества платформы AWS М2.
• Автоматизированный рефакторинг: преобразует унаследованные приложе-
ния на устаревших языках в адаптивные сервисы на базе Java, использующие
AWS Bln Age, соответствующие современным веб-фреймворкам и лучшим
практикам облачных процессов DevOps.
• Смена платформы: миграция приложений, написанных на COBOL, выполня-
ется с использованием интегрированного инструментария Micro Focus, с мо-
дернизацией инфраструктуры, но при сохранении языка программирования,
обеспечивая адаптивность с облачно-ориентированными операциями DevOps.
Модернизация унаследованного кода с помощью GenAI 595
• Репликация данных и передача файлов: функциональность мейнфреймов
улучшается благодаря выполняемой практически в реальном времени ре-
пликации данных в Precisely и средствам передачи файлов ВМС Software.
• Тестирование приложений: автоматизирует проверку модернизированных
приложений на базе мейнфрейма, сокращая расходы и ускоряя тестирование
за счет использования масштабируемого облачно-ориентированного сервиса.
Этот сервис сочетается с растущей потребностью в модернизации унаследован-
ных систем, предоставляя полноценное решение для компаний, переходящих
с традиционной инфраструктуры мейнфрейма на более адаптивные и эконо-
мичные облачные среды. Узнать больше можно на странице AWS: https://aws.
amazon.com/mainframe-modernization/.
По возможности выполняйте миграцию мейнфреймов поэтапно, чтобы со-
кратить сложность и риск. При поэтапной миграции команды могут быстрее
предоставить обратную связь в отношении процесса миграции, а компании могут
использовать эту обратную связь, чтобы оптимизировать внутренние процессы
и ускорить миграцию. По мере того как генеративный ИИ приобретает популяр-
ность и встраивается во многие готовые продукты, он может ускорить процесс
модернизации. В следующем разделе эта тема рассматривается более подробно.
Модернизация унаследованного кода
с помощью GenAI
Модернизация унаследованного кода с помощью GenAI представляет собой
передовой подход к разработке ПО. Инструменты генеративного ИИ могут
анализировать и понимать унаследованный код, часто написанный на уста-
ревших языках программирования, и помогать переписывать или переводить
его на современные, более эффективные языки или фреймворки. Этот про-
цесс ускоряет модернизацию кода и помогает сохранить функциональность
унаследованных систем одновременно с использованием преимуществ со-
временных технологий.
Автоматизируя часть процесса преобразования кода, генеративный ИИ сокра-
щает объем ручной работы и уровень необходимой квалификации, делая процесс
модернизации более доступным и снижая риск ошибок. Такой подход в основном
приносит пользу компаниям, которые стремятся обновить старые системы без
ущерба для эффективности эксплуатации. Модернизация унаследованного кода
с генеративным ИИ включает такие инструменты, как Codex, часть предложений
OpenAI (обеспечивает работу GitHub Copilot) и, потенциально, фундаменталь-
ные модели. Эти средства применяют ИИ для понимания унаследованного кода
и его рефакторинга на более современные и эффективные языки или фреймвор-
ки. Например, Codex может интерпретировать старые, менее распространенные
языки программирования и предоставлять рекомендации или прямые переводы
на более современные языки — такие, как Python или JavaScript. Это упрощает
596
Глава 15. Переработка архитектуры унаследованных систем
обновление унаследованных систем, делая их удобнее в обслуживании и более
совместимыми с современными практиками разработки.
Также заслуживает упоминания Amazon CodeWhisperer — ассистент на базе
ИИ для написания кода, созданный компанией AWS. Как и GitHub Copilot, он
помогает разработчикам, предлагая рекомендации по написанию кода и авто-
матизируя некоторые задачи программирования. Инструмент может повысить
производительность разработчика, помочь с применением лучших практик
и, возможно, с модернизацией унаследованного кода, предлагая современные
приемы написания кода и решения. CodeWhisperer, интегрированный в рабочий
процесс разработчика, может значительно упростить обслуживание, обновле-
ние и оптимизацию кода, включая перевод или рефакторинг унаследованных
систем. CodeWhisperer также предоставляет контекстные рекомендации, чтобы
обеспечить повторное использование библиотек кода и последовательное при-
менение паттернов программирования.
Кроме того, фундаментальные модели, обученные на разнообразных данных
из многих предметных областей, могут помочь с пониманием сложного уна-
следованного кода, выявляя лишние или неэффективные сегменты и предлагая
варианты оптимизации или современные паттерны программирования.
Интеграция этих инструментов в процесс модернизации ускоряет преобразо-
вание унаследованного кода. Она способствует созданию более простых в об-
служивании, масштабируемых и безопасных программных систем, а это очень
важно для любой компании, стремящейся сохранить конкурентоспособность
в стремительно развивающейся цифровой среде.
Итоги
В этой главе вы узнали о проблемах, присущих унаследованным приложениям,
и о том, почему так важно эти приложения модернизировать. Были рассмотрены
преимущества, которые может получить организация при обновлении своих
приложений до новейших технологий. Модернизация приложений может быть
сложной и рискованной, но обычно затраченные усилия окупаются.
Результат, полученный в результате обновления, должен быть сопоставим с за-
тратами на его достижение. Прежде чем определять способ модернизации, не-
обходимо хорошо разобраться в унаследованной системе и провести тщательную
оценку приложения в отношении технологии, архитектуры и кода.
Следующий шаг после оценки — определение способа модернизации. Вы узна-
ли о разных существующих вариантах, включая модернизацию, управляемую
архитектурой, переработку системы и миграцию. Также были рассмотрены раз-
личные приемы модернизации систем, как простые (инкапсуляция и рехостинг),
так и сложные (переработка архитектуры и перепроектирование). Облачные
технологии предлагают значительные преимущества, и вы ознакомились с под-
ходом к принятию решений при модернизации в облаке. Вы узнали о проблемах,
Итоги 597
связанных с модернизацией мейнфреймов, и о преимуществах облачных техно-
логий, упрощающих путь модернизации. Наконец, вы узнали, как генеративный
ИИ может повысить эффективность разработчика, выступая в роли ассистента
по обновлению унаследованного кода.
Мы изучали разные технические параметры архитектуры решений; однако
одним из важнейших элементов проектирования архитектуры, который обес-
печивает удобство обслуживания системы в долгосрочной перспективе, явля-
ется документация. В следующей главе обсуждаются документы, необходимые
архитектору решений для участия в создании и поддержания максимальной
ценности для бизнеса.
ГЛАВА 16
ДОКУМЕНТИРОВАНИЕ
АРХИТЕКТУРЫ РЕШЕНИЙ
В предыдущих главах вы узнали о различных вопросах проектирования и оп-
тимизации архитектуры решений. В ходе работы над дизайном архитектору
решений очень важно выстроить последовательную коммуникацию с другими
стейкхолдерами для успешной поставки приложения. Архитектор решений
должен донести результаты проектирования до всех технических и нетехниче-
ских стейкхолдеров.
Документ по архитектуре решения (SAD, Solution Architecture Document)
содержит комплексное представление приложения и гарантирует, что все
участники проекта будут иметь одинаковые представления о решении и будут
работать согласованно. В этой главе будут рассмотрены разные параметры SAD,
которая призвана удовлетворить потребности всех стейкхолдеров, связанные
с разработкой приложения.
Вы узнаете о структуре SAD и других типах документов, о которых должен знать
архитектор решений, — таких, как запрос предложений (request for proposal,
RFP), где архитектору необходимо предоставить вводные данные для принятия
стратегических решений. Чтобы лучше разобраться в документе по архитектуре
решения, рассмотрим следующие темы.
• Назначение SAD.
• Представления (views) SAD.
• Структура SAD.
• Жизненный цикл SAD.
• Лучшие практики и типичные ловушки SAD.
• Документация на закупки для архитектуры решения.
К концу главы вы будете знать о документе по архитектуре решения, его струк-
туре и деталях, которые он должен содержать. Вы узнаете о видах документации
на приобретение (запрос на предложение, запрос информации, запрос цены
и т. д.), к составлению которой архитектор решений привлекается как поставщик
обратной связи. Начнем с основ, а именно — с назначения SAD.
Назначение SAD 599
Назначение SAD
Зачастую потребности в документации на архитектуру игнорируются и команды
начинают работать над реализацией без общего понимания архитектуры. SAD
содержит общее представление всей архитектуры решения в целях информи-
рования всех стейкхолдеров. Он важен для многих стейкхолдеров, включая
руководителей проектов, которые полагаются на этот документ при коорди-
нировании и отслеживании прогресса проекта. Бизнес-аналитики используют
SAD для совмещения проекта с требованиями бизнеса. Технические команды,
включая разработчиков и IT-специалистов, обращаются к SAD при реализации
и обслуживании предлагаемых решений. Старший менеджмент использует
этот документ для принятия обоснованных стратегических решений. Наконец,
клиенты или конечные пользователи, на которых и рассчитан продукт, тоже
зависят от SAD — он гарантирует, что результат проекта будет соответствовать
их потребностям и ожиданиям.
SAD решает следующие задачи:
• распространение информации о комплексном решении между всеми клю-
чевыми участниками;
• высокоуровневый обзор архитектуры и представлений структуры решения
для удовлетворения требований к качеству сервиса (надежность, безопас-
ность, производительность, масштабируемость);
• обеспечение соответствия решения бизнес-требованиям и знания о том, как
приложение будет удовлетворять всем функциональным (ФТ) и нефункцио-
нальным (НФТ) требованиям;
• описание всех представлений решения, необходимых для проектирования,
построения, тестирования и реализации;
• определение последствий решения для целей оценки, планирования и по-
ставки;
• определение бизнес-процесса, длительности и операций, необходимых для
бесперерывной работы решения после запуска продукта.
SAD определяет цель и назначение решения. В нем упоминаются такие крити-
чески важные компоненты, как ограничения, предположения и риски, о которых
часто забывает команда реализации. Архитектор решений должен следить, чтобы
документ был написан простым языком, понятным для бизнес-пользователей,
и бизнес-контекст в нем должен быть соотнесен с техническим дизайном. Доку-
мент помогает сохранить информацию на случай ухода специалистов и снижает
зависимость проектирования от человеческого фактора.
Для приложений, требующих модернизации, SAD содержит абстрактное пред-
ставление текущей и будущей архитектуры, а также план перехода. Архитектор
решений понимает зависимости существующей системы и документирует их,
чтобы заранее избежать потенциальных рисков. План миграции помогает бизнесу
600 Глава 16. Документирование архитектуры решений
выбрать инструменты и технологии, необходимые для запуска новой системы,
и соответствующим образом спланировать ресурсы.
Архитектор решений в процессе проектирования проводит различные оценки,
создавая подтверждение концепции (РОС) или проводя исследования рынка.
В SAD должны быть перечислены все оценки архитектуры и их влияние, а также
подходящие варианты технологий. SAD содержит концептуальное представление
текущего и целевого состояний архитектуры решения, а также историю изме-
нений. В следующем разделе рассматриваются варианты представлений SAD.
Представления SAD
Архитектор решений должен разработать SAD, понятный как для бизнеса, так
и для технических пользователей. SAD служит промежуточным звеном в комму-
никации между бизнес-пользователями и командой разработки, обеспечивающим
понимание функций приложения в целом. Лучший способ воспринять входную
информацию от всех стейкхолдеров — поставить себя на их место и взглянуть
на задачи с их точки зрения. Архитектор решений оценивает параметры проек-
тирования архитектуры со стороны как технологий, так и бизнеса и учитывает
все технические и нетехнические требования пользователей.
Как показано на рис. 16.1, общая структура SAD включает представления (views)
различных параметров, обусловленных бизнес-требованиями.
Рис. 16.1. Представления SAD
Представления SAD 601
Для описания различных представлений архитектор решений может выбрать
стандартные диаграммы — например, диаграммы UML (Unified Modeling
Language) или блоковые диаграммы из Microsoft Visio. Эти популярные ин-
струменты помогают передавать сложные архитектурные концепции в доступном
формате. В целом диаграмма должна быть удобочитаемой и понятной для всех
стейкхолдеров со стороны бизнеса и технологий. SAD должен по возможности
включать следующие представления для потребностей всех сторон.
• Бизнес-представление: проектирование архитектуры учитывает потребно-
сти бизнеса и направлено на решение бизнес-задач. Бизнес-представление
показывает ценностное предложение решения и продукта. Чтобы упростить
задачу, архитектор решений может выявить высокоуровневые сценарии, от-
носящиеся к бизнесу, и представить их в виде диаграммы юзкейсов. Бизнес-
представление также описывает стейкхолдеров и ресурсы, необходимые для
исполнения проекта. Бизнес-представление также можно рассматривать как
представление сценариев использования (юзкейсов).
• Логическое представление: описывает различные пакеты системы, чтобы
бизнес-пользователи и дизайнеры системы понимали, из каких логических
компонентов она состоит. Логическое представление предлагает упорядочен-
ное по времени описание создания системы. Оно показывает, как системные
пакеты соединяются между собой и как пользователь может взаимодейство-
вать с ними. Например, в банковском приложении пользователь сначала
должен пройти аутентификацию и авторизацию с использованием пакета
безопасности, получить доступ к счету с использованием пакета счетов,
подать заявку на кредит с использованием пакета кредитов и т. д. Каждый
пакет представляет собой отдельный модуль и может быть построен в форме
микросервиса.
• Процессное представление: подробнее показывает, как критически важные
процессы системы взаимодействуют друг с другом. Для него можно использо-
вать диаграмму состояния. Чтобы раскрыть подробности, архитектор решений
может создать диаграмму последовательности. В банковском приложении
процессное представление может касаться процесса утверждения заявки на
кредит или предоставления доступа к счету.
• Представление развертывания: показывает, как приложение будет функцио-
нировать в продакшен-среде. Оно демонстрирует соединения компонентов
системы (таких, как сетевой файрвол, балансировщик нагрузки, серверы
приложений и база данных). Для него лучше создать простую блоковую диа-
грамму, понятную для пользователей со стороны бизнеса. На UML-диаграмму
развертывания можно добавить больше информации, чтобы показать узлы
и зависимости между ними для технических пользователей (например,
команд разработки и DevOps). Представление развертывания описывает
физическую структуру системы.
602 Глава 16. Документирование архитектуры решений
• Представление реализации: занимает центральное место в SAD; описывает
архитектурные и технологические решения. Оно должно содержать архи-
тектурную диаграмму (например, если это 3-уровневая, N-уровневая или
управляемая событиями архитектура) и обоснования выбора архитектуры.
Также будет полезно разместить подробные описания выбора технологий —
например, использования Java вместо Node.js с достоинствами и недостатками
обоих вариантов. В представлении реализации следует дать обоснование всем
ресурсам и навыкам, необходимым для выполнения проекта. Команда разра-
ботки использует представление реализации для создания детализированной
структуры (например, диаграммы классов), но включать эту информацию
в SAD необязательно.
• Представление данных: большинство приложений работает на основе
данных, поэтому представление данных играет ключевую роль. Оно пока-
зывает, как данные перемещаются между компонентами и как они хранятся.
Также представление данных может пояснять принципы безопасности
и целостности данных. Архитектор решений может использовать диа-
грамму сущностей и связей для демонстрации отношений между разными
таблицами и схемами базы данных. Подробнее о диаграммах сущностей
и связей см. в подразделе «Архитектура данных» раздела «Архитектура
решения» в этой главе. Представление данных также указывает на необ-
ходимые отчеты и аналитику.
• Операционное представление: объясняет, как будет осуществляться обслу-
живание системы после запуска. Часто здесь определяются соглашения об
уровне обслуживания (SLA), функциональность оповещений и мониторинга,
план аварийного восстановления и план поддержки системы. Операционное
представление также подробно описывает, как будет выполняться обслужи-
вание системы — например, исправление ошибок, установка обновлений,
резервное копирование и восстановление, а также действия при инцидентах
безопасности.
Если SAD содержит все перечисленные представления, он покрывает все пара-
метры системы и потребности стейкхолдеров. Можно включить дополнительные
представления — например, представление физической архитектуры, пред-
ставление сетевой архитектуры или представление архитектуры безопасности,
если этого потребуют ключевые участники. Архитектор решений должен рас-
сматривать функционирование системы и понимать, как она работает, с разных
позиций. В следующем разделе структура SAD рассматривается более подробно.
Структура SAD
Структура SAD может различаться в зависимости от требований стейкхолдеров
и природы проекта. Проект может подразумевать создание нового продукта
с нуля, модернизацию унаследованного приложения или перемещение всей
системы в облако.
Структура SAD 603
В разных проектах SAD может быть разным, но в общем должен учитывать ин-
тересы различных стейкхолдеров, а также содержать разделы, представленные
на рис. 16.2.
СОДЕРЖАНИЕ
1. Обзор решения
1.1. Цель решения
1.2. Объем решения
1.2.1. Что входит в объем решения
1.2.2. Что не входит в объем
решения
1.3. Допущения
1.4. Ограничения
1.5. Зависимости
1.6. Ключевые архитектурные решения
2. Бизнес-контекст
2.1. Бизнес-потенциал
2.2. Ключевые бизнес-требования
2.2.1. Ключевые бизнес-процессы
2.2.2. Стейкхолдеры со стороны
бизнеса
2.3. Нефункциональные требования
2.3.1. Масштабируемость
2.3.2. Доступность и надежность
2.3.3. Производительность
2.3.4. Портируемость
2.3.5. Безопасность
3. Концептуальный обзор решения
3.1. Концептуальная и логическая
архитектура
4. Архитектура решения
4.1. Информационная архитектура
4.1.1. Информационные
компоненты
4.2. Архитектура приложения
4.2.1. Компоненты приложения
4.3. Архитектура данных
4.3.1. Поток данных и контекст
4.4. Архитектура интеграции
4.4.1. Интерфейсный компонент
4.5. Архитектура инфраструктуры
4.5.1. Компоненты инфраструктуры
4.6. Архитектура безопасности
4.6.1. Управление
идентификационными
данными и доступом
4.6.2. Модель угроз для
приложения
5. Реализация решения
5.1. Разработка
5.2. Развертывание
5.3. Миграция данных
5.4. Вывод приложения
из эксплуатации
6. Управление решением
6.1. Управление эксплуатацией
6.1.1. Мониторинг и оповещения
6.1.2. Поддержка и управление
инцидентами
6.1.3. Аварийное восстановление
6.2. Онбординг пользователей
6.2.1. Пользовательские
требования к системе
7. Приложение
7.1. Открытые вопросы
7.2. Выводы из РОС (подтверждения
концепции)
Рис. 16.2. Структура SAD
604 Глава 16. Документирование архитектуры решений
Представленная структура SAD содержит разделы, относящиеся к разным
параметрам архитектуры решений и проектирования. Архитектор реше-
ний может добавить или удалить какие-то разделы, если это обусловлено
требованиями к проекту. Например, можно добавить вводный раздел для
описания цели и краткого резюме документа. Для проекта миграции можно
добавить подраздел с описанием существующей архитектуры, сравнением ее
с целевой и т. д.
Рассмотрим каждый раздел более подробно.
Обзор решения
Обзор решения содержит краткое, на 1-2 абзаца, описание решения. Здесь
в общих чертах описываются функциональность решения и его компонен-
ты. Полезно будет добавить общую блоковую диаграмму, показывающую
все компоненты. На рис. 16.3 представлен обзор решения для платформы
интернет-магазина.
Рис. 16.3. Обзор решения для интернет-магазина
Структура SAD 605
Необходимо дать простое и краткое описание каждого компонента, чтобы бизнес-
пользователь мог понять общую схему работы решения. Например, на диаграмме
выше типичный процесс заказа в интернет-магазине и работа цепочки поставок
изображены в упрощенном виде.
• Клиентский заказ.
Процесс начинается, когда клиент размещает заказ на сайте интернет-
магазина или маркетплейса.
Поддержка клиентов играет важную роль, помогая клиентам с заказами,
отвечая на вопросы и решая проблемы, которые могут возникнуть в про-
цессе заказа.
• Цепочка поставок и управление заказами.
Оформление заказа: после размещения заказа он регистрируется как
оформленный, что запускает процесс его исполнения.
Данные о наличии товара: система проверяет данные, чтобы убедиться,
что заказанные товары имеются в наличии.
Уведомление об отправке: после того как заказ будет обработан и готов
к отправке, система посылает уведомление — оно также может включать
информацию для клиента по отслеживанию посылки.
• Обработка заказа.
Платеж: обработка платежа клиента, включая применение любых налогов
и промокодов.
Налог: расчет и применение правильного налога на продажи в зависимости
от местоположения клиента и приобретенных товаров.
Логистика: организация доставки заказа к местоположению клиента.
Исполнение заказа: непосредственный отбор, упаковка и подготовка
к отправке заказанных товаров.
Отправка: процесс отправки заказа для доставки.
Акции: применение скидок или специальных предложений, которые могут
быть частью заказа.
Уведомления: отправка клиенту сведений о статусе заказа.
Возврат: обработка процедуры возврата, если клиент будет недоволен
покупкой или если с заказом возникли проблемы.
Отмена: обработка отмены заказа, если клиент решит отменить заказ до
его отправки.
Эти элементы обеспечивают эффективную обработку пользовательских заказов
с момента их размещения и до выполнения.
Затем приводится краткий обзор решения, включающий следующие подразделы.
• Цель решения: содержит краткое описание бизнес-проблемы, для которой
предназначается решение, и обоснование для построения этого решения.
В сценарии выше решение предназначено для оптимизации и автоматизации
606 Глава 16. Документирование архитектуры решений
процесса управления заказом в цепочке поставок. Описание должно разре-
шать бизнес-проблемы, связанные с эффективностью, точностью и удовлет-
ворением клиентов при исполнении заказов.
• Объем решения: здесь формулируется область действия предлагаемого
решения и четко описываются элементы, выходящие за его пределы. Объем
решения включает сквозную автоматизацию системы управления заказами,
от размещения заказа клиентом до уведомления об отправке. Он не включает
действия клиента после доставки — например, обработку обратной связи
или возврата.
• Допущения: список всех допущений, сделанных архитектором при разработке
решения. Например, в нашем сценарии решение предполагает наличие ми-
нимальной пропускной способности сети для обработки данных в реальном
времени. Также предполагаются возможность интеграции с различными тор-
говыми площадками и службами доставки и доступность систем цифровых
платежей для клиентов.
• Ограничения: список всех бизнес-ограничений, а также ограничений, касаю-
щихся технологий и ресурсов. Часто существуют отраслевые или норматив-
ные ограничения — они также должны быть перечислены в этом разделе.
Кроме того, можно выделить риски и составить план их снижения. Решение
должно соответствовать нормативам защиты данных — таким, как GDPR
для обеспечения конфиденциальности данных клиентов в Евросоюзе или
PCI-DSS для хранения платежной информации клиентов в США. Ресурсные
ограничения включают фиксированный бюджет и сроки развертывания.
Также могут присутствовать технические ограничения, обусловленные ин-
теграцией унаследованных систем.
• Зависимости: список всех предшествующих и последующих зависимостей.
Например, сайт интернет-магазина должен взаимодействовать с почтовыми
сервисами (такими, как UPS или FedEx) для доставки посылок. Решение
зависит от складских данных реального времени для точной обработки за-
казов от системы управления складскими запасами. Оно требует интеграции
с платежными шлюзами для проведения финансовых транзакций.
• Ключевые архитектурные решения: формулировки важных проблем и пред-
лагаемые решения. Описание достоинств и недостатков каждого варианта
и причин выбора того или иного решения.
• Для примера возьмем решение о применении облачной платформы для обес-
печения масштабируемости. Она была выбрана благодаря своей способности
поддерживать изменяющиеся объемы заказов и снижать необходимые на-
чальные капитальные вложения. Компромиссом такого решения являются
постоянные операционные расходы.
• Другим решением может быть создание в первую очередь API для
интеграции. Этот подход обеспечит гибкость и простоту интеграции
Структура SAD 607
с партнерами и сервисами. С другой стороны, он повысит сложность
управления API.
После обзора решения необходимо связать его с бизнес-контекстом. В следу-
ющем разделе рассмотрим представление бизнес-контекста более подробно.
Бизнес-контекст
В разделе бизнес-контекста архитектор решений должен представить общий
обзор бизнес-потенциала и требований, для которых создается решение. В этот
раздел включается только абстрактное представление требований. Подробные
требования перечисляются и описываются в отдельном документе, ссылку на
который можно предоставить в этом разделе. Он включает следующие основные
подразделы.
• Бизнес-возможности: краткое описание бизнес-возможностей, для которых
проектируется решение. Обязательно должно включать их преимущества
с указанием того, как перечисленные возможности будут удовлетворять
потребности клиентов.
• Ключевые бизнес-требования: перечисление всех ключевых бизнес-
проблем, для которых предназначено решение. Следует изложить общее
представление ключевых требований и добавить ссылку на документ с их
подробным описанием.
• Ключевые бизнес-процессы: описание ключевых процессов. На рис. 16.4
изображено упрощенное представление модели бизнес-процессов прило-
жения интернет-магазина.
• Бизнес-стейкхолдеры со стороны бизнеса: перечислите стейкхолдеров, на
которых прямо или косвенно влияет проект. К их числу относятся спонсоры,
разработчики, конечные пользователи, поставщики и партнеры.
• Нефункциональные требования (НФТ): архитекторы решений должны
уделять больше внимания НФТ, так как их часто упускают из виду бизнес-
пользователи и команда разработки. В целом НФТ должны включать:
масштабируемость: как приложение сможет масштабироваться при
колебаниях рабочей нагрузки? (Например, масштабирование от 1000 до
10 000 транзакций в секунду в течение дня или месяца.);
доступность и надежность: какое время простоя считается приемлемым
для доступности системы? (Например, 99,99 % доступность или 45-ми-
нутный период неработоспособности за месяц.);
производительность: какие требования предъявляются к производи-
тельности? Как система сможет справиться с нагрузкой без ущерба для
взаимодействий конечного пользователя? (Например, время загрузки
страницы каталога не должно превышать 3 секунд.);
608 Глава 16. Документирование архитектуры решений
портируемость: сможет ли приложение сразу работать на нескольких
платформах? (Например, мобильное приложение должно работать в опе-
рационных системах iOS и Android.);
емкость: с какой максимальной рабочей нагрузкой может справиться
приложение? (Например, максимальное количество пользователей, ко-
личество запросов, ожидаемое время ответа и ожидаемое время загрузки
приложения.)
( Получение I
I заказа J
I Проверка 1
I запасов j
I уведомления j
1
f Обновление статуса 1
I заказа j
Рис. 16.4. Диаграмма бизнес-процессов интернет-магазина
Структура SAD 609
Концептуальное представление архитектуры предоставляет полный обзор
системы для бизнес-стейкхолдеров и технологий. Рассмотрим концептуальное
представление более подробно.
Концептуальный обзор решения
Концептуальный обзор решения представляет диаграмму абстрактного уровня,
отражающую общую картину всего решения, включая технические и бизнес-
параметры. Она служит основой для анализа и изучения компромиссов, что по-
могает уточнить и оптимизировать архитектуру решения в объеме, достаточном
для проектирования и реализации. На рис. 16.5 изображена концептуальная
архитектурная диаграмма интернет-магазина.
Сервис учетных записей
База данных
учетных записей
Сервис доставки
Сервис складских запасов
База данных
доставки
База данных
складских запасов
Рис. 16.5. Концептуальная архитектурная диаграмма интернет-магазина
На диаграмме изображено абстрактное представление важных модулей и по-
токов информации между ними. Концептуальная диаграмма обеспечивает
хорошее понимание общей архитектуры как для бизнес-, так и для технических
пользователей. При этом техническим пользователям необходимо больше
610 Глава 16. Документирование архитектуры решений
архитектурных деталей. В следующем разделе архитектура решения рассма-
тривается более подробно.
Архитектура решения
В разделе архитектуры решения глубже рассматривается каждая часть архитек-
туры. Здесь содержатся разные представления, которые могут использоваться
технической командой при создании подробной архитектуры и работе над
реализацией. Эти представления могут быть ориентированы на другие группы
пользователей: разработчиков, инженеров инфраструктуры, инженеров DevOps,
инженеров безопасности и UX-дизайнеров.
Информационная архитектура
Этот подраздел в общих чертах описывает навигацию пользователя в при-
ложении. Как показано на рис. 16.6, на сайте интернет-магазина для перехода
к нужной странице пользователю достаточно трех кликов.
Главная
Продукты
Контакты
Домой
Игрушки
Одежда
Продукты
питания
Мой профиль
Заказы
Профиль
Способы
оплаты
Электро-
ника
Телефоны
Телевизоры
Рис. 16.6. Диаграмма информационной архитектуры интернет-магазина
Архитектор решений может добавить дополнительную информацию: нави-
гацию по сайту, таксономию или высокоуровневую каркасную модель,
которая используется UX-дизайнерами для создания детализированного
вайрфрейма.
Структура SAD 611
Архитектура приложения
Этот раздел предназначен для команды разработки. Он содержит больше подроб-
ностей реализации для архитектора или команды разработки в целях создания
подробного дизайна. На рис. 16.7 изображена архитектура приложения для сайта
интернет-магазина, содержащая такие структурные элементы, как кэширование,
сети, распространение контента и хранение данных.
Рис. 16.7. Диаграмма архитектуры приложения для интернет-магазина
На диаграмме необходимо перечислить компоненты архитектуры приложения,
которые нужны для обеспечения онлайн-покупок на облачной платформе ин-
тернет-магазина. К числу таких компонентов относятся следующие.
• Пользовательские взаимодействия: клиенты взаимодействуют с платформой
интернет-магазина через веб-интерфейс, начиная с безопасного размещения
заказа, совершаемого через SSL (Secure Sockets Layer) для шифрования
передачи данных.
• Поставка контента: Amazon CloudFront — сеть поставки контента (CDN) —
эффективно поставляет пользователям статический контент: графику,
таблицы стилей, клиентские скрипты. Кэширование контента рядом с ме-
стоположением пользователя сокращает задержку.
• DNS (Domain Name System): Amazon Route 53 используется для управ-
ления DNS, направляя пользовательские запросы наиболее подходящим
эндпоинтам — например, в CloudFront или балансировщику нагрузки
приложения.
612 Глава 16. Документирование архитектуры решений
• Обработка, выполняемая приложением: внутри виртуального частного об-
лака VPC (Virtual Private Cloud) приложение интернет-магазина обрабаты-
вает динамические запросы — например, выполняет рендеринг страницы на
основании пользовательских профилей и истории покупок. Сервис рекомен-
дации товаров внутри VPC предлагает персонализированные рекомендации
пользователям на основании их поведения и предпочтений.
• Механизм кэширования: Amazon ElastiCache применяется для ускорения
выборки данных за счет кэширования данных, к которым часто совершаются
обращения, — например, состояния сессии и информации часто просматри-
ваемых товаров. Тем самым сокращаются нагрузка на базы данных бэкенда
и время реакции приложения.
• Хранение и обработка данных: сервис оформления заказов управляет взаи-
модействиями пользователя с покупательской корзиной и транзакциями.
Данные кэша сессии и каталога сохраняются для быстрого доступа. Поис-
ковая система на базе Amazon Elasticsearch предоставляет мощные средства
поиска по каталогу товаров.
• Пользовательские профили и данные транзакций: информация пользова-
тельских профилей вместе с данными транзакций хранится в сервисе Amazon
DynamoDB, обеспечивающем быструю и масштабируемую функциональность
баз данных No SQL.
• Журналы данных: Amazon S3 используется для хранения разного рода жур-
нальных данных: данных посещений, взаимодействий с продуктом, системных
журналов и т. д. Это позволяет проводить углубленный анализ и извлекать
данные о поведении пользователя и эффективности системы.
В этом разделе перечисляются все модули приложения, которые следует вывести
из эксплуатации, сохранить, переместить на другую платформу или преобразо-
вать для модернизации архитектуры.
Архитектура данных
Этот раздел в основном используют администраторы баз данных и команда раз-
работки, чтобы понять схемы баз данных и отношения между таблицами. В него
часто включается диаграмма сущностей и связей (ERD, Entity-Relationship
Diagram), показывающая отношения между наборами сущностей, хранящимися
в базе данных (рис. 16.8).
Event
РК EventJD
Event-Type
Event_Name
Event_Loc
Order
PK OrderJD
Order_Number
OrderJType
Order_Quarrtity
Order_Data
Ship. Address
Рис. 16.8. Диаграмма сущностей и связей для платформы интернет-магазина
Структура SAD 613
Диаграмма ERD содержит наглядное представление сущностей (обычно
соответствующее таблицам баз данных) и отношений между ними. Это гра-
фический инструмент, используемый при проектировании баз данных для
демонстрации их логической структуры. На рис. 16.8 показан пример ERD
для системы обработки заказов. Диаграмма демонстрирует связи между про-
исходящими событиями и заказами, обрабатываемыми в системе. Назовем
компоненты и связи между ними.
• Сущность Event (событие): представляет собой явление или действие внутри
системы с такими атрибутами, как Event_ID (первичный ключ), Event_Type,
Event_Name и Event_Loc. Эти атрибуты могут содержать подробную инфор-
мацию о том, что собой представляет событие, где оно произошло, а также
другие характеристики.
• Сущность Order (заказ): представляет собой заказ клиента с такими атри-
бутами, как Order_ID (первичный ключ), Order_Number (номер заказа),
Order_Type (тип заказа), Order_Quantity (количество), Order_Date (дата
заказа) и Ship_Address (адрес доставки). Эти атрибуты содержат информа-
цию, относящуюся к каждому заказу: объем заказа, подробная информация
о доставке, дата оформления и т. д.
• Сущность OrderProcessing (обработка заказа): является ассоциативной
сущностью (или таблицей соединения), связывающей Event с Order; показы-
вает, что Event приводит к обработке Order. Имеет собственный первичный
ключ (Processing_EventID) и содержит внешние ключи Event_ID и Order_ID,
связанные с сущностями Event и Order соответственно. Присутствие атрибута
Order_Event_date указывает, что в нем хранится информация о том, когда
обрабатывается событие, приводящее к заказу.
Линии между сущностями представляют собой отношения. На этой диа-
грамме ERD «птичья лапка» в конце линий отношений означает «многие»,
тогда как одиночная линия означает «один»; эти значки показывают мощность
связей.
В разделе архитектуры данных перечисляются все объекты данных, которые
должны учитываться при разработке приложения.
Архитектура интеграции
Архитектурой интеграции называется расширенная основа, позволяющая разным
приложениям, системам и сервисам взаимодействовать и эффективно работать
совместно. Она включает проектирование и реализацию методов и промежуточ-
ных инструментов, упрощающих обмен данными и процессы между разными
системами в организации или между организацией и внешними участниками.
Этот раздел в основном предназначен для поставщиков, партнеров и других
команд. Например, на рис. 16.9 показаны все точки интеграции с другими си-
стемами в приложении интернет-магазина.
614
Глава 16. Документирование архитектуры решений
Каталог товаров
(Й—
_ Торговый представитель
Рис. 16.9. Диаграмма архитектуры интеграции для интернет-магазина
В разделе архитектуры интеграции перечислены все системы, которые предо-
ставляют данные приложению. Здесь указываются любые платформы, сервисы
или базы данных, от которых приложение получает данные, а также природа
потоков данных и подробная информация о системах, которым приложение
отправляет данные. Это могут быть другие приложения, базы данных или
сервисы, зависящие от данных, производимых или обрабатываемых прило-
жением. Необходимо перечислить все системные зависимости, относящиеся
к приложению.
Архитектура инфраструктуры
Этот раздел предназначен прежде всего для команды инфраструктуры
и системных инженеров. В него необходимо включить диаграмму развер-
тывания с указанием логичного местоположения сервера и зависимостей.
Например, на рис. 16.10 представлена диаграмма развертывания приложе-
ния интернет-магазина. Можно добавить отдельные диаграммы для других
сред — например, сред разработки, контроля качества (QA) и приемочного
тестирования (UAT).
Структура SAD 615
Рис. 16.10. Диаграмма развертывания интернет-магазина
В этом разделе перечисляются все конфигурации серверов, все базы данных,
сети и коммутаторы для развертывания приложения.
Архитектура безопасности
В этом разделе описываются параметры безопасности и комплаенса.
• Управление идентификационными данными и доступом (IAM, identity and
access management) — например, Active Directory (AD), механизм аутенти-
фикации пользователей и управление авторизацией.
• Инфраструктурные средства безопасности: конфигурация файрвола, система
предотвращения вторжений (IPS, intrusion prevention system) / система
обнаружения вторжений (IDS, intrusion detection system) и антивирусные
программы.
• Средства безопасности приложений — такие, как файрволы веб-приложений
(WAF) и защита от распределенных атак отказа в обслуживании (DDoS).
• Безопасность данных при хранении и передаче с использованием SSL, алго-
ритмов шифрования, управления ключами и т. д.
Архитектор решений также может включить модель угроз безопасности при-
ложения для выявления потенциальных уязвимостей (таких, как межсайтовый
скриптинг (XSS) или SQL-инъекции (SQLi)) и планировать защиту приложения
от любых угроз безопасности.
616
Глава 16. Документирование архитектуры решений
Реализация решения
В разделе реализации решения приводятся основные соображения, которые
должны учитываться при разработке и развертывании решения. Он может со-
держать следующие основные подразделы.
• Разработка: этот подраздел важен прежде всего для команды разработки.
В нем обсуждаются инструменты разработки, язык программирования,
репозиторий кода, система контроля версий кода и ветвление, а также при-
водятся обоснования для выбора тех или иных вариантов.
• Развертывание: этот подраздел предназначен в основном для инженеров
DevOps, и в нем рассматриваются метод развертывания, инструменты раз-
вертывания, различные компоненты и чек-лист развертывания, а также
приводятся обоснования для выбора тех или иных вариантов.
• Миграция данных: этот подраздел поможет команде понять миграцию дан-
ных и механизм поглощения данных, область действия миграции, различные
объекты данных, используемые средства поглощения, источники и форматы
данных и т. д.
• Вывод приложения из эксплуатации: в этом подразделе перечисляются су-
ществующие системы, которые необходимо вывести из эксплуатации, а также
стратегия выхода для текущей системы, если показатель окупаемости не
достигнут. Архитектор решений должен предоставить метод и план-график
вывода старой системы из эксплуатации и оценить его общий эффект.
SAD включает общее описание подхода к разработке и инструментов. При этом
она не предполагает описания подробной структуры уровня приложения, такого
как диаграмма классов или псевдокод. Такие подробности должен указать архи-
тектор продукта или сеньор-разработчик в соответствующем дизайн-документе
для продукта. После развертывания приложением необходимо будет управлять
в продакшен-среде. В следующем разделе рассматривается, какую информацию
необходимо включать в раздел управления решением.
Управление решением
Раздел управления решением предназначен для поддержки продукта и теку-
щего обслуживания системы в других непродуктовых средах. В этом разделе
рассматриваются параметры эксплуатации решения, включая мониторинг,
управление инцидентами, онбординг пользователей, процессы поддержки
и восстановления.
Структура SAD 617
Раздел управления решением в основном предназначен для команды эксплуа-
тации. Он раскрывает следующие темы.
• Операционное управление: установка патчей, обновление сред разработки,
тестирования, стейдж- и продакшен-среды.
• Инструменты для управления обновлениями приложения и выпуска новых
версий.
• Инструменты для управления инфраструктурой системы.
• Мониторинг системы и оповещения; операционный дашборд.
• Поддержка продакшен-среды, SLA и управление инцидентами.
• Аварийное восстановление и непрерывность бизнес-процессов (ВРС,
business process continuation).
Архитектор решений должен анализировать и собирать данные для проверки
решения в процессе проектирования. Дополнительные подробности можно
включить в раздел SAD «Приложение», который мы рассмотрим далее.
Приложение
Как любой документ, описывающий бизнес-предложение, SAD предусматри-
вает открытый раздел «Приложение», который содержит все данные, поддер-
живающие общую архитектуру и выбор тех или иных решений. В этот раздел
архитектор решений может включить открытые вопросы и любые данные
исследований: результат РОС, данные сравнения инструментов, данные от по-
ставщиков и партнеров и т. д.
Итак, мы представили полезный обзор структуры SAD. SAD должен включать
основные перечисленные разделы; тем не менее архитектор решений может ис-
ключить или добавить некоторые из них под конкретные требования организации
или проекта. Как и в случае с другими документами, важно регулярно обращать-
ся к SAD и искать возможности для улучшения. Хорошо проработанные SAD
обеспечивают четкие рекомендации по реализации и сокращают риск ошибок.
SAD — активный документ, который создается на начальной стадии проекта
и обновляется постоянно на основании изменений в жизненном цикле прило-
жения. Рассмотрим основные точки жизненного цикла SAD.
618 Глава 16. Документирование архитектуры решений
Жизненный цикл SAD
Жизненный цикл SAD соотносится с этапами жизненного цикла проекта. Ранее
в этой главе мы изучали разделы SAD, которые создаются на соответствующих
этапах работы. Жизненный цикл SAD обычно включает следующие этапы
(рис. 16.11).
Рис. 16.11. Жизненный цикл SAD
Рассмотрим некоторые лучшие практики и типичные ошибки при создании SAD.
Лучшие практики и типичные ошибки SAD
Эффективное управление SAD включает применение некоторых лучших
практик. Очень важно, чтобы документ оставался ясным и лаконичным, его
содержание было доступным и при этом обходилось без технического жаргона.
Регулярное участие стейкхолдеров в работе над документацией обеспечит ее со-
ответствие бизнес- и техническим требованиям. Исключительно важно поддер-
живать актуальность SAD в соответствии с последними изменениями в проекте.
Документация на закупку IT-ресурсов для архитектуры решения
619
Кроме того, следует всегда соотносить архитектуру, описанную в SAD, с более
широкими бизнес-целями организации; это обеспечит поддержку и расширение
бизнес-целей предлагаемыми техническими решениями.
При работе над SAD необходимо избегать распространенных ошибок. Чрезмер-
ное усложнение архитектуры может затруднить реализацию и обслуживание.
Отсутствие гибкости в документе может помешать его адаптации к изменениям
объема или целей проекта. Недостаточное вовлечение стейкхолдеров может
привести к несоответствию документа фактическим потребностям бизнеса.
Более того, некачественная документация может стать источником недопо-
нимания, ошибок реализации и проблем исполнения проекта. Важно помнить
об этих потенциальных ошибках и не допускать их, чтобы обеспечить успех
архитектуры решения.
Помимо SAD, архитектура решения часто включает масштабный закупочный
процесс с особым требованием — документом типа «запрос на X» (RFx, Request
For х). В следующем разделе документ RFx рассматривается более подробно.
Документация на закупку IT-ресурсов
для архитектуры решения
Документация на закупку IT-ресурсов обычно называется RFx. Этот термин
объединяет разные стадии процесса закупки. Сокращение RFx относится к фор-
мальному процессу запроса на покупку. Документы RFx делятся на запросы
предложений (RFP, Request For Proposal), запросы информации (RFI, Request
For Information) и запросы цены (RFQ, Request For Quotation).
Архитекторы решений часто участвуют в процессе закупок, либо руководя им,
либо предоставляя информацию. Приобретение может относиться к услугам
аутсорсинга, заключению договоров, закупке программного обеспечения (на-
пример, баз данных или инструментов разработчика) или решений SaaS.
Поскольку такие документы могут содержать техническую информацию и с боль-
шой вероятностью будут иметь широкое, долгосрочное влияние, архитектор реше-
ния должен предоставить данные в соответствии с потребностями в приобретении.
Рассмотрим, чем же различаются перечисленные разновидности документов RFx.
• RFI: документы RFI относятся к ранней стадии закупочного процесса,
когда покупатели запрашивают информацию у разных поставщиков, чтобы
в дальнейшем принять обоснованное решение. Документ RFI содержит
информацию о возможностях разных поставщиков, чтобы покупатель мог
сравнить их по одинаковым параметрам и продолжить работу с поставщи-
ками, прошедшими предварительный отбор. Например, компания изучает
рынок систем управления обучением (LMS, Learning Management System),
чтобы выбрать наиболее подходящую. Компания выпускает RFI для сбора
подробной информации о функциональности, возможностях интеграции
и пользовательских взаимодействиях доступных платформ LMS.
620 Глава 16. Документирование архитектуры решений
• RFP: в этом процессе поставщики, прошедшие предварительный отбор,
получают дополнительную информацию о результате проекта. Документ
RFP обычно более открытый, чем RFI, и поставщики могут предоставить
покупателю оптимальный вариант приобретения решений. Поставщик может
предложить несколько вариантов с описаниями достоинств и недостатков
каждого. Например, правительственное агентство хочет обновить свою
IT-инфраструктуру. Оно публикует RFP с описанием текущей системы,
требуемых улучшений и критериев эффективности. Поставщики отвечают
предложениями, содержащими технические решения, сроки реализации
проекта и оценку стоимости.
• RFQ: в этом процессе покупатели сужают требования по сравнению с RFP
и формируют конкретный их список в отношении работы, оборудования
и объема поставки. Поставщики должны указать затраты по указанным
требованиям, а покупатель выбирает лучшее предложение и заключает
контракт. Например, технологический стартап готовится масштабировать
свою IT-инфраструктуру для растущей базы пользователей. Ему необходимы
дополнительные облачные вычислительные ресурсы для увеличивающейся
нагрузки. Требования в отношении вычислительных экземпляров, памяти,
хранилища и пропускной способности уже определены. RFQ предлагает
поставщикам IT-инфраструктуры представить свои варианты ежемесячных
и годовых тарифов, а также скидки при заключении долгосрочных контрактов.
Стартап также запрашивает дополнительные услуги: поддержку, мониторинг
и средства безопасности, которые могут быть включены в цену.
RFP — самый популярный вариант, так как для ускорения процесса организа-
ция-покупатель часто ограничивается запросом у потенциальных поставщиков
только таких документов. В этом случае документ RFP должен иметь четкую
структуру, чтобы покупатель мог сравнить выбранных поставщиков в отно-
шении возможностей, методов реализации и затрат и быстро принять решение.
Из-за технического характера приобретений в IT-организациях роль архитектора
решений очень важна при оценке возможностей и методов поставщиков с точки
зрения покупателя и ответа на запрос RFP со стороны поставщика. В процессе
RFP для рабочей нагрузки большую роль играет экспертная оценка архитектора
решений. Его участие в процессе может выглядеть так.
1. Понимание требований: архитектор решений начинает с подробного ана-
лиза требований проекта — как технических, так и бизнес-требований. Они
могут включать расширение существующих систем, миграцию на облачную
платформу или интеграцию новых технологий.
2. Проектирование решения: архитектор создает предварительный проект
IT-архитектуры, удовлетворяющий выявленным требованиям. Он включает
выбор подходящих технологий, проектирование инфраструктуры и анализ
возможностей интеграции с существующими системами.
Документация на закупку IT-ресурсов для архитектуры решения
621
3. Совместная работа: архитектор часто сотрудничает с многофункциональ-
ными группами, включающими бизнес-аналитиков, менеджеров проектов
и техлидов, чтобы обеспечить соответствие приложения бизнес-целям и воз-
можность его технической реализации.
4. Оценка ресурсов: архитектор оценивает ресурсы, необходимые для проекта:
оборудование, программное обеспечение, облачные сервисы и рабочее время
с точки зрения конкурентоспособности и реалистичности предложения.
5. Оценка рисков: архитектор выявляет потенциальные риски в проекте и пред-
лагает стратегии их преодоления, включаемые в ответ RFP.
6. Документация: архитектор помогает создать подробную техническую до-
кументацию с объяснением того, как предлагаемое решение удовлетворяет
требованиям RFP. Документация часто включает системные диаграммы,
диаграммы потоков данных и детальные описания предлагаемой среды.
7. Стратегия ценообразования: архитектор может совместно с финансовой
группой разрабатывать стратегии ценообразования для предложения. Это
гарантирует, что затраты будут соответствовать предлагаемой ценности.
8. Представление: архитектор решений может входить в команду, представ-
ляющую предложение потенциальному клиенту. Он объясняет технические
нюансы и отвечает на любые технические вопросы.
Архитектор решений необходим, чтобы создаваемое предложение не только
удовлетворяло требования клиента, но и было технологически жизнеспособ-
ным и экономически эффективным. Например, если компания запрашивает
предложения новой системы CRM на базе облака, архитектор решений сначала
анализирует существующую архитектуру IT и оценивает необходимые параме-
тры — такие, как масштабируемость и безопасность данных. Он проектирует
облачное решение, которое бесшовно интегрируется с текущими системами,
такими как ERP, и сочетается с маркетинговыми стратегиями. В сотрудничестве
с потенциальными поставщиками архитектор обеспечивает соответствие вы-
бранных платформ CRM специфическим потребностям компании и оценивает
их совместимость. Кроме того, он тесно сотрудничает с юридическим отделом,
чтобы решение отвечало жестким требованиям к соответствию нормативам по
управлению персональными данными.
Ключевой задачей является создание стратегии миграции для переноса данных
из старых систем в новую CRM с минимальным периодом неработоспособности.
Также важно оценить суммарную стоимость владения и учесть такие факторы,
как затраты на подписку, настройка, передача данных и необходимость обучения
персонала. Архитектор решений участвует в создании чернового варианта техни-
ческой части ответа RFP, где подробно описываются предлагаемая архитектура,
стратегия данных и меры безопасности. Он формулирует план реализации,
уделяя внимание таким аспектам, как масштабирование системы со временем
и структура поддержки после развертывания.
622 Глава 16. Документирование архитектуры решений
Кроме того, архитектор решений представляет и защищает техническую стра-
тегию перед лицами, ответственными за принятие решений со стороны кли-
ента, демонстрируя преимущества и практичность предлагаемого решения.
Он помогает убедить клиента, что тот инвестирует в надежную, безопасную
и масштабируемую систему, которая поддерживает рост бизнеса и адаптируется
к развивающимся требованиям рынка.
Итоги
SAD служит для обеспечения единого представления о проблеме всеми стейкхол-
дерами, а также для формального согласования структуры решения и требований.
Поскольку к числу стейкхолдеров относятся и технические, и бизнес-пользо-
ватели, мы рассмотрели виды представлений SAD, которые должен учитывать
архитектор решений. Необходимо предусмотреть представления для нетехниче-
ских пользователей — например, бизнес-представление, представление процесса
и логическое представление. Для технических пользователей следует включить
представления приложения, разработки, развертывания и эксплуатации.
В этой главе подробно рассмотрена структура SAD со всеми ее основными раз-
делами и подразделами.
В разных разделах SAD содержится разнообразная информация, в том числе
обзор решения, описание архитектуры в бизнес-контексте и описание концеп-
туальной архитектуры. Вы познакомились с различными представлениями
архитектуры на архитектурных диаграммах, включая архитектуры приложе-
ния, данных, инфраструктуры, интеграции и безопасности. Вы также узнали
о других разделах SAD, в которых описываются контекст поставки решения
и управление операциями.
Наше путешествие было долгим. Вы почти дочитали книгу, но прежде чем за-
вершать ее, дадим несколько советов, как стать архитектором решений и улуч-
шить свои знания.
В следующей — последней — главе книги рассматриваются гибкие навыки (soft
skills), которые помогут вам стать более опытным архитектором решений: стили
коммуникации, критическое мышление и техники непрерывного обучения.
ГЛАВА 17
ГИБКИЕ НАВЫКИ,
КОТОРЫЕ НУЖНЫ ХОРОШЕМУ
АРХИТЕКТОРУ РЕШЕНИЙ
В предыдущих главах мы рассказывали, что архитектор решений должен учиты-
вать потребности всех стейкхолдеров. Несмотря на то что архитектор решений —
это технический специалист, он работает на разных уровнях организации, от
высшего руководства до команд разработки. Гибкие навыки (soft skills) — необ-
ходимое и критически важное условие успешной карьеры архитектора решений.
Архитектор должен следить за трендами технологий, расширять свои знания
и всегда быть готовым узнавать новое. Чтобы стать хорошим архитектором
решений, необходимо непрерывное обучение. В этой главе рассматриваются
методы изучения новых технологий, а также возможности участвовать и вносить
вклад в техническое сообщество.
Архитектор должен определять и представлять общую техническую стратегию,
направленную на реализацию потребностей бизнеса. Ему необходимо работать
с техническими и бизнес-командами для нахождения лучшего решения, что
требует превосходных коммуникационных навыков. В этой главе вы узнаете,
какие гибкие навыки (включая коммуникационные) должен иметь архитектор
решений. Мы рассмотрим следующие темы.
• Важность гибких навыков.
• Приобретение навыков предварительных продаж.
• Принятие владения и ответственности за результат.
• Гибкость и адаптируемость.
• Дизайн-мышление.
• Непосредственное участие в написании кода.
• Развитие благодаря непрерывному обучению.
• Роль ментора.
• Роль технологического евангелиста и лидера мнений.
624 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
К концу этой главы вы будете знать о гибких навыках, необходимых успешному
архитектору решений. Вы узнаете, как приобрести стратегические навыки (такие,
как навыки предварительных продаж и коммуникации на высшем уровне), а так-
же как развить дизайн-мышление и лидерские качества (масштабное мышление
и принятие владения). Вы узнаете, как занять позицию лидера и продолжить
совершенствовать свой набор навыков.
Важность гибких навыков
Важность гибких навыков для архитектора решения трудно переоценить, так как
они являются неотъемлемой составляющей его эффективности и успеха.
На первом месте — эффективные коммуникации. Архитектор решений должен
уметь упрощать сложные технические подробности для нетехнических стейк-
холдеров, обеспечивая ясность и соответствие бизнес-целей техническим. Этот
навык чрезвычайно важен для налаживания связей между техническими и ком-
мерческими подразделениями, что упрощает взаимопонимание и совместную
разработку целей.
Налаживание сотрудничества и командной работы — еще один важная задача
архитектора. Так как ему часто приходится работать в кроссдисциплинарных
командах, он должен уметь эффективно общаться с людьми, имеющими разную
степень подготовки и опыт. Сотрудничество важно для разрешения конфлик-
тов, достижения консенсуса и формирования среды общей ответственности
и коллективного успеха.
Важнейшими навыками для архитектора решений являются также навык
решения задач и критическое мышление. Архитектор должен уметь ориен-
тироваться в сложных технических проблемах и находить инновационные
решения, соотносящиеся с бизнес-стратегиями. Для этого потребуются по-
нимание технологий, креативность, аналитическое мышление и ориентиро-
ванность на поиск решений.
Наконец, лидерство и адаптируемость также играют важную роль. Архитек-
торы решений часто занимают лидерские позиции в проектных командах,
осуществляя техническое руководство и принимая поворотные решения. Это
требует навыков лидерства, а также умения вдохновлять, мотивировать и на-
правлять деятельность команд к общим целям. Кроме того, технологическая
сфера непрерывно меняется, поэтому адаптируемость и ориентированность на
обучение позволяют архитекторам идти в ногу со временем и реагировать на
новые тенденции и технологические сдвиги. Эти гибкие навыки в сочетании
с техническим опытом делают архитектора решений бесценным сотрудником
в любой организации.
В следующих разделах рассматриваются некоторые ключевые гибкие навыки,
которыми должен обладать архитектор решений в рамках более общих навыков,
перечисленных в этом разделе.
Приобретение навыков предварительных продаж 625
Приобретение навыков предварительных
продаж
Предпродажный этап — чрезвычайно важная часть приобретения сложных
технологий, когда заказчик собирает подробную информацию для принятия
решения о покупке. В организации клиента архитектор решений участвует
в предпродажном цикле для проверки технологических и инфраструктурных
ресурсов от различных поставщиков. В организации поставщика он отвечает на
запросы предложений (RFP) и представляет потенциальное решение, позволяю-
щее получить нового клиента. Для этого ему требуется особый набор навыков.
Ключевые навыки
Предпродажа требует особого набора навыков, включающего сильные техниче-
ские знания и гибкие навыки.
• Коммуникации и ведение переговоров: архитектору решений необходимы
отличные навыки коммуникации для общения с клиентами и передачи
актуальной информации. Точные детали решения и его актуальность для
отрасли помогут клиенту понять, как оно может решить его бизнес-пробле-
му. Архитектор решения служит связующим звеном между отделом продаж
и техническими командами, поэтому коммуникация и координация очень
важны. Архитекторы решений также должны обеспечивать соглашения,
сотрудничая с клиентами и внутренними командами, для чего необходимы
отличные навыки ведения переговоров. В частности, решения стратегического
уровня оказывают значительное влияние на несколько групп. Архитекторы
решений должны вести переговоры между командами, прорабатывать ком-
промиссы и создавать оптимизированные решения.
• Слушание и решение задач: архитектору необходимы сильные аналитические
навыки, чтобы определить решение, соответствующее потребностям клиента.
Архитектор решений должен слушать и понимать юзкейсы клиента, а также
задавать правильные вопросы. Он должен уметь видеть пробелы и разраба-
тывать решения, помогающие достичь бизнес-результатов немедленно и оку-
паемые в долгосрочной перспективе. Для одних клиентов может быть более
важна производительность, тогда как для других — затраты, в зависимости
от пользовательской базы приложения. Архитектор должен предоставить
подходящее решение в соответствии с основными KPI клиента.
• Клиентоориентированность: архитектору часто приходится работать как
с внутренними, так и с внешними заказчиками. Архитектор влияет на
стейкхолдеров на всех уровнях, от руководителей высшего звена до инже-
неров-разработчиков. Он представляет решения и демоверсии старшему
руководству, которое рассматривает предложение с точки зрения бизнеса.
Поддержка руководителей высшего звена и их приверженность инициати-
вам всегда служат залогом успеха выбранного решения, поэтому навыки
626 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
клиентоориентированности играют очень важную роль. Руководители выс-
шего звена изучают подробности решения на специально организуемой
встрече, и архитектор должен использовать выделенное время максимально
эффективно. Коммуникация с высшим руководством более подробно рас-
сматривается в следующем разделе этой главы.
• Работа с командами: архитектор формирует отношения с командами
бизнеса и продукта. Чтобы разработать оптимальное приложение, архи-
тектор решений должен взаимодействовать с техническими и бизнес-
командами на всех уровнях. Архитектор решений должен уметь работать
в команде, обмениваться идеями и искать возможности для сотрудничества
команд.
Указанные навыки необходимы для предпродаж; кроме того, они применимы
и в повседневной работе архитектора. Архитекторами становятся технические
специалисты, и на такой позиции им необходимо развивать навыки коммуника-
ции на всех уровнях. Коммуникация с высшим руководством рассматривается
в следующем разделе.
Представление решения руководителям высшего звена
Архитектор решения должен уметь решать различные технические и бизнес-
вопросы. Одной из самых сложных задач может стать получение одобрения со
стороны руководства.
Руководители высшего звена - это генеральный директор (СЕО), технический
-(Zh- ] директор (СТО), финансовый директор (СЕО), руководители направлений,
z\/4 J IT-директор (СЮ). Такие руководители имеют напряженный рабочий график
и принимают много ответственных решений.
Архитектор решений должен представить множество подробностей, но встречи
с руководителями высшего звена ограничены по времени. Поэтому необходимо
извлечь за выделенное время максимум практической пользы. Главный вопрос:
как добиться внимания и поддержки старшего руководства за ограниченное время?
Начните с объяснения повестки и запланированной структуры встречи. Ру-
ководители задают много вопросов, и вы должны предусмотреть время для
уточняющих вопросов и ответов. В презентации решения руководителям самое
важное — дать краткое резюме основных тезисов за первые 5 минут. Вы должны
быть готовы к тому, чтобы передать суть проекта и получить одобрение для
следующего шага, даже если запланированная получасовая встреча сократится
до этих пяти минут.
Предоставьте сводку фактов и данных, имеющих отношение к отрасли и орга-
низации. Держите подробности наготове на случай, если руководители захотят
глубже изучить конкретный вопрос; будьте готовы быстро получить и предста-
вить все необходимые данные.
Приобретение навыков предварительных продаж 627
Не пытайтесь изложить все подробности, в том числе информацию, которая
может казаться важной вам, но не имеет особого смысла для руководства.
Например, вам как архитектору решений могут быть важны преимущества
технической реализации. При этом руководство будет больше интересовать
величина окупаемости за счет сокращения расходов на эксплуатацию и повы-
шения эффективности.
Используйте в своей демонстрации или презентации отраслевую и клиентскую
терминологию. Термины и концепции, знакомые слушателям, не только фор-
мируют доверие, но и свидетельствуют, что вы адаптировали свое техническое
решение для эффективного решения специфических проблем.
При общении с руководителями приготовьтесь ответить на следующие вопросы.
• Какую пользу предлагаемое решение принесет нашим клиентам? В биз-
несе центральное место занимает клиент. Целью руководителей является
рост компании, а он возможен только в том случае, если клиенты довольны.
Обязательно проведите исследования клиентской базы и ее потребно-
стей. Будьте готовы описать преимущества, подкрепленные надежными
данными.
• На каких предположениях основан выбор базовых параметров решения?
Часто встречи с руководством проводятся на начальном этапе, когда нужна
более подробная информация. Архитекторы решений всегда должны сделать
несколько допущений, которые станут основой решения. Составьте список
гипотез и подготовьте запасной план на случай, если предположения ока-
жутся неверными.
• Какая окупаемость предполагается? При определении суммарной стои-
мости владения (total cost of ownership, ТСО) руководители всегда учи-
тывают окупаемость (ROI). Рассчитайте оценочную стоимость владения,
затраты на обслуживание решения, расходы на обучение, размер общей
экономии и т. д.
• Что будет, если мы оставим все как есть и ничего не сделаем? Для выясне-
ния окупаемости высшее руководство может устраивать очень тщательный
разбор предлагаемых решений. Руководителям необходимо понимать, оправ-
даются ли вложения. Желательно иметь наготове результаты исследований
рынка — например, технологических и клиентских тенденций и анализа
конкурентов.
• Как наши конкуренты отреагируют на решение? Конкуренция повсюду,
и руководители думают о ней. Они хотят понять, будет ли ваше решение
достаточно инновационным, чтобы превзойти конкурентов и предоставить
организации преимущество. Лучше заранее провести соответствующие
исследования и добавить данные о конкурентах, касающиеся их отрасли
и клиентской базы.
• Что вы предлагаете и как я могу помочь? Во время презентации предложе-
ний у вас всегда должен быть наготове краткий список конкретных действий,
628 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
запланированных на следующий этап. Вам нужно заручиться одобрением
руководства и вовлечь его в проект, обратившись за содействием. Например,
можно попросить у IT-директора связать вас с инженерной командой или
командой продукта, чтобы перевести решение на следующий этап.
В следующем разделе рассматриваются лидерские навыки, которыми должен
обладать архитектор решений как техлид организации.
Принятие владения и ответственности
за результат
Принятие владения решением и позиционирование себя в качестве лидера
помогут завоевать доверие благодаря принятию ответственности за результат.
Владение не означает, что вы будете делать все самостоятельно: это подразуме-
вает выбор новых инициатив и внедрение их в организации. У вас могут быть
идеи, способные принести практическую пользу организации в отношении
производительности, адаптивности, экономии и расширения клиентской базы.
Иногда реализация идеи требует большого количества времени или ресурсов,
но стоит предложить ее как новую инициативу и привлечь к ее реализации
других сотрудников.
При этом вы принимаете на себя ответственность за полученный результат.
Владение и ответственность за результат связаны: вы создаете инициативу
и работаете над ее реализацией. Вам доверяют выполнение работы и достиже-
ние результата. Ответственность способствует формированию доверительных
отношений с клиентами и командой, что формирует благоприятную рабочую
среду и помогает достичь поставленной цели.
Для архитектора решений принятие владения помогает увидеть ситуацию с точ-
ки зрения клиентов и спонсоров. Вы чувствуете себя частью чего-то значимого,
что вам нравится. Постарайтесь определить цели и ключевые результаты. Цель/
результат должны быть измеримы по конкретным ключевым показателям и огра-
ничены по времени. Система целей и ключевых результатов (OKR, Objectives
and Key Results) более подробно рассматривается в следующем разделе.
Определение исполнения стратегии с учетом OKR
Исполнение стратегии — комплексная и сложная задача. Успешное исполнение
стратегии необходимо для понимания видения, миссии и целей организации.
Идея должна трансформироваться в действия, которые можно выполнить,
чтобы команды работали согласованно и все двигались в одном направлении.
Постановка целей и управление ими — один из самых проверенных способов
достижения результатов.
Метод OKR представляет принципы и практики (вйдение и исполнение) по-
становки целей. OKR — система управления стратегией, уделяющая основное
Принятие владения и ответственности за результат 629
внимание исполнению; простая основа, которая позволяет определить перво-
очередные стратегии и приоритеты организации. Цели — это принципы,
а ключевые результаты — практики, соответственно отвечающие на вопросы
«что?» и «как?». В основе OKR лежат четыре движущие силы, показанные
на рис. 17.1.
• Фокус: начните с вопроса: каковы наши основные приоритеты и на чем
необходимо сосредоточить усилия? Стремитесь к тому, что на самом деле
важно, и доступно объясните, чего вы добиваетесь.
• Согласованность: сделайте цели открытыми и прозрачными. Связывайтесь
с командой и обеспечивайте горизонтальную и вертикальную согласован-
ность, а также согласованность внутри команды.
• Отслеживание: обеспечьте наглядное отслеживание ключевых результатов
по каждой цели в процентах.
• Амбициозные цели: ставьте цели по достижению действительно заметных
результатов. Амбициозные цели помогают переосмысливать ситуацию.
Методика OKR задает ясные, измеримые цели и согласует их со стратегической
миссией организации. В архитектуре решений OKR может направлять ход про-
ектирования и реализации систем, чтобы обеспечить их вклад в глобальные
цели бизнеса.
Согласованность
Движущие силы
OKR
Амбициозные цели
Рис. 17.1. Движущие силы OKR
630 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Для архитектора решений OKR могут выглядеть примерно так.
Цель: повышение стабильности и отказоустойчивости системы.
Ключевые результаты:
• снижение времени неработоспособности системы на 30 % за следующий
квартал;
• реализация мультизонной стратегии развертывания для критически важных
сервисов к следующему циклу выпуска;
• достижение 99,99 % доступности для пользовательского уровня приложения
в течение 6 месяцев.
В этом примере архитектор использует OKR для постановки четких целей по
производительности и надежности системы, которые входят в число его важней-
ших зон ответственности. OKR также помогают назначать приоритеты задачам,
оценивать прогресс и доводить информацию о последствиях архитектурных
решений до стейкхолдеров.
Метод OKR обеспечивает видимость и представление значимых результатов
всем стейкхолдерам на разных уровнях, от руководящих спонсоров проекта
до рабочих команд. OKR проясняют вйдение и миссию организации. Вйдение
и ясная формулировка миссии необходимы членам команд в их повседневной
работе; они должны понимать, как их действия влияют на цели. OKR позволяет
определить эту связь и представить общее вйдение и значимость происходящего
всем участникам команд.
Масштабное мышление
Архитектор решений должен быть способен видеть общую картину и прогнози-
ровать будущее. Он создает основу, на которой команда размещает стандартные
блоки и запускает продукт. Масштабность мышления — один из важнейших
навыков, которыми должен обладать архитектор решений для обеспечения
долговечности приложения.
Масштабное мышление не означает, что вы должны ставить нереалистичные
цели. Но цель должна быть достаточно амбициозной, чтобы потребовать от вас
значительных усилий и вывести из зоны комфорта.
По сути, масштабное мышление направлено на прогнозирование потребностей
организации и опережение технологических достижений, чтобы текущий ди-
зайн можно было адаптировать для будущих потребностей, поддерживая его
эффективность. Масштабное мышление необходимо для достижения успеха
как на персональном уровне, так и на уровне организации.
Мысля масштабно, оставайтесь уверенными в своих способностях. Сначала задача
может казаться сложной, но вы непременно найдете нужный путь, когда начнете
двигаться к цели. Поверьте в себя, и вы заметите, что другие начинают вас поддер-
живать и верить в вас. Масштабное мышление помогает вдохновлять окружающих,
Гибкость и адаптируемость 631
чтобы они стали частью вашего успеха. Ставьте долгосрочные цели — например,
отвечая на вопрос, как вы видите себя и свою организацию в следующем десятилетии.
Шаг за шагом трансформируйте краткосрочные цели в долгосрочные.
Постановка амбициозных целей за счет масштабного мышления поможет вам
взять инициативу на себя и исследовать новые возможности. Тем не менее для
достижения результата желательно заручиться поддержкой со стороны коллег
и команды, которые могут предоставить необходимую обратную связь и оказать
содействие. Станьте тем, кому захотят помогать другие; впрочем, это работает
в обоих направлениях. Чтобы получить помощь, вы должны быть открыты для
помощи другим. Адаптируемость — еще один важнейший навык архитекторов
решений, необходимый, чтобы работать с другими людьми. В следующем раз-
деле он рассматривается более подробно.
Гибкость и адаптируемость
Адаптируемость и гибкость тесно взаимосвязаны, и архитектор решений должен
проявлять достаточную гибкость, чтобы адаптироваться к новым средам, рабочим
культурам и технологиям. Адаптируемость означает, что вы всегда открыты для
новых идей и работы с соответствующими им командами.
Команды могут использовать процессы и технологии, которые лучше всего
им подходят. Архитектор решений должен быть достаточно гибким, чтобы
учитывать требования команд на этапе проектирования решения. Например,
в микросервисной архитектуре каждый сервис взаимодействует через стандарт-
ный API RESTful по протоколу HTTP. Команды могут писать код на разных
языках: Python, Java, Node.js или С#. Единственное требование заключается
в том, чтобы все команды предоставляли безопасный доступ к API и вся система
могла строиться на его использовании.
Вам потребуется менять образ мышления и точку зрения на проблемы, а также
уметь находить инновационные решения. Если команды будут придерживаться
принципа быстрого провала (fail fast) и внедрять инновации, это поможет орга-
низации оставаться конкурентоспособной.
Перечислим некоторые проявления гибкости.
• Умение видеть разные возможные решения задач в команде и выбирать
лучший способ.
• Помощь участникам команды с делегированием работы.
• Добровольное согласие занять место в команде, если какому-то участнику
требуется покинуть ее на несколько недель по личным обстоятельствам.
• Умение эффективно сотрудничать с командами в разных регионах и часовых
поясах.
Необходимо сохранять открытость и уметь адаптироваться к изменениям тех-
нологий и процессов. При внедрении изменений в команде или организации
можно столкнуться с сопротивлением. Необходимо убеждать других проявлять
632 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
гибкость и разъяснять важность изменений. Например, если организация хочет
переместить свою рабочую нагрузку из локальной среды в облако, ей обычно
требуется больше поддержки, так как разработчикам приходится изучать новую
платформу. Необходимо рассказать о пользе перехода в облако и о том, как это
поможет сотрудникам действовать более адаптивно и ускорить инновации.
Архитектор решений должен уметь работать в режиме многозадачности и назна-
чать приоритеты выполнения. Он должен уметь подстраиваться под ситуацию
и работать в условиях стресса.
Архитектор решений должен обладать критическим дизайн-мышлением, чтобы
создавать инновационные решения. Эта тема более подробно рассматривается
в следующем разделе.
Дизайн-мышление
Архитектор решений играет ведущую роль в проектировании систем, поэтому
навык дизайн-мышления ему критически необходим. Дизайн-мышление — один
из самых успешных подходов, внедряемых в разных отраслях для решения слож-
ных и неочевидных задач. Оно помогает рассматривать задачи и решения с новой
точки зрения, которую заранее нужно тщательно продумать. Дизайн-мышление
в основном направлено на получение результатов за счет применения подхода,
ориентированного на решение. Оно дает возможность критически оценивать
задачу, решение и сопутствующие риски для разработки оптимальной стратегии.
Дизайн-мышление помогает переопределять задачи с учетом клиентоориенти-
рованности, для чего следует поставить себя на место конечных пользователей
и клиентов. На рис. 17.2 показаны основные принципы дизайн-мышления.
Назовем некоторые принципы дизайн-мышления.
• Частые эксперименты: создайте прототип, чтобы понять реализацию идеи
в реальных сценариях. Внедрите стратегию быстрого провала (fail fast) и экс-
периментируйте чаще.
• Разноплановое сотрудничество: привлекайте людей с разным опытом рабо-
ты, чтобы представлять проблемы с разных точек зрения, и следите, чтобы
решения учитывали все потребности.
• Фокус на клиента: собирайте обратную связь от разных пользователей.
Ставьте себя на их место, чтобы взглянуть на задачу под другим углом.
• Наглядная демонстрация: выразите свои мысли в наглядной форме, чтобы
вашим собеседникам было проще понять их.
• Четкое определение задачи: создайте четко определенное и понятное видение
задачи, которое поможет другим понять ее и стимулирует к участию в ее
решении.
• Продуманный процесс проектирования: четко представьте себе общий про-
цесс проектирования с ясными целями и методами.
Дизайн-мышление 633
Частые
эксперименты
Продуманный процесс
проектирования
Разноплановое
сотрудничество
Ориентация
на действия
Рис. 17.2. Принципы дизайн-мышления
• Ориентация на действия: конечная задача проектирования — поставить го-
товое, а не мысленное решение. Будьте проактивны и совершайте действия,
которые приведут вас к работоспособному решению.
Дизайн-мышление лежит в основе эмпатии и создания целостного представления
задачи. Для выработки дизайн-мышления существует модель из пяти этапов,
предложенная d.school (https://dschool.stanford.edu/resources/getting-started-with-
design-thinking) — пионерами в обучении дизайн-мышлению и его применении.
Эти этапы показаны на рис. 17.3.
Дизайн-мышление — итеративный подход, который должен непрерывно раз-
виваться. Выходные данные одного этапа могут рекурсивно передаваться на
вход других этапов, пока решение не примет конечную форму. Вот краткое
описание этапов.
• Эмпатия, то есть способность к сопереживанию, — структурный элемент
и основа проектирования в человеческом контексте. Чтобы сопережи-
вать, необходимо наблюдать за поведением пользователей и общаться
с ними; это позволит понять суть проблемы. Попробуйте углубиться
в проблему и почувствовать ее на себе, представив себя в соответствующей
ситуации.
634
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Эмпатия
Определение
Оформление идеи
Разработка прототипа
Тестирование
Рис. 17.3. Пять этапов дизайн-мышления
• Определение: эмпатия помогает определить задачу, когда вы переживаете
потребности пользователя и проблемы, с которыми он сталкивается. На этапе
определения вы применяете полученные выводы и четко формулируете за-
дачу, что может инициировать мозговой штурм для поиска инновационного,
но простого решения.
• Оформление идеи: суть этого этапа заключается в переходе от задачи
к решению. Вы работаете с командой и ищете альтернативные решения,
пересматривая предположения. Не зацикливайтесь на очевидном решении
и работайте совместно в поисках всех возможных решений, что открывает
возможность инноваций.
• Разработка прототипа: прототипирование помогает преобразовать идеи
в конкретные решения. Прототипы могут стать отличным обучающим
материалом и помогут устранить разногласия за счет демонстрации под-
тверждения концепции (РОС). Это поможет выявить пробелы и риски.
Прототип должен создаваться быстро и без значительных вложений, помогая
преодолевать сбои и повышать качество обучения.
• Тестирование: этот этап подразумевает получение обратной связи по решению
и его соответствующий пересмотр. Тестирование помогает переопределить
решение и больше узнать о пользователях.
Дизайн-мышление объединяет все перечисленные этапы в разработку логичного
и практического решения. При проектировании архитектуры решения можно
связать этапы и принципы дизайн-мышления с реальными ситуациями. Осо-
бенно важно создать прототип, так как это единственный способ подтвердить
ваше предложение и существующие решения данными и фактами. Главная за-
дача архитектора решений — понять интересы бизнеса и разработать прототип
Развитие благодаря непрерывному обучению 635
технического решения, которое может реализовать команда. Чтобы создать про-
тотип, архитектору решений придется засучить рукава и заняться написанием
кода. В следующем разделе эта тема рассматривается подробнее.
Участие в написании кода
Архитектор решений — строитель, который учится на практике. Прототип стоит
тысячи схем. Он помогает устранить любые недоразумения и оформить идею
решения. Представление РОС и прототипирование — неотъемлемые составля-
ющие работы архитектора решений.
Прототипирование — этап, предшествующий построению решения, углубляю-
щий понимание дизайна приложения и особенностей пользователя. Прототип
помогает в осмыслении и построении разных путей решения. Тестируя прототип,
можно улучшить решение и вдохновить других (например, команды, клиентов
и инвесторов) демонстрацией своего видения.
Архитектор решений — это технический лидер, который тесно взаимодействует
с командой разработки. В динамичной команде талантливых разработчиков
архитектор решений должен представить в качестве РОС фрагмент кода в до-
полнение к презентации PowerPoint. Архитектор решений не обязан быть частью
команды разработки, но он должен продемонстрировать решение на понятном
ей языке. Поставка будет успешной только в том случае, если архитектор реше-
ний сможет вникнуть в технические параметры решения, которые становятся
понятны только при написании кода и на практическом опыте.
К архитектору решений часто относятся как к ментору или играющему тренеру;
практический кодинг помогает наладить доверительные отношения. Архитектор
решений подбирает языки программирования и инструменты для команды.
Практический подход помогает выявить элементы, которые могут не соответ-
ствовать требованиям команды или продукта, — постоянное изучение новых
технологий поможет вам принимать лучшие решения в интересах организации.
Рассмотрим непрерывное обучение более подробно.
Развитие благодаря непрерывному обучению
Архитектор решений должен непрерывно получать новые знания и расширять
свой кругозор, чтобы помогать организации принимать более эффективные
решения. Непрерывное обучение поддерживает актуальность набора навыков
архитектора и формирует доверие в команде. Оно помогает мыслить объективно
и при необходимости менять точку зрения.
Полная занятость и личная жизнь оставляют мало времени для обучения. Суть
непрерывного обучения — формирование привычки всегда узнавать что-то
новое, для чего потребуется мотивация и дисциплина. Прежде всего необходи-
мо поставить цели обучения и для их достижения использовать эффективные
методы тайм-менеджмента.
636
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Разным людям нужны разные стили обучения. Одним лучше подходит формаль-
ное образование; другие выбирают чтение книг; третьи предпочитают слушать
и смотреть обучающие ролики. Найдите то, что наиболее эффективно лично
для вас и лучше всего подходит к вашему стилю жизни.
Например, можно слушать аудиокниги и учебники по дороге на работу. Можно
читать книги во время деловых перелетов или смотреть обучающее видео во
время занятий в фитнес-центре. В целом вам придется постараться, чтобы выде-
лить время из занятой жизни на непрерывное обучение. Ниже рассматриваются
некоторые способы мотивировать себя к непрерывному обучению.
• Изучайте новые технологии, фреймворки и языки, применяя их на практике:
архитекторы решений должны быть готовы к практическим экспериментам.
Успешный архитектор решений должен осваивать новые технологии на неболь-
ших проектах. Понимание современных языков программирования и фрейм-
ворков поможет рекомендовать организации и команде лучшие технологии.
• Осваивайте новые навыки, читая книги и учебники: у традиционного чтения
бумажных книг много преимуществ, особенно в контексте целенаправлен-
ного обучения. Книги изолируют от отвлекающих факторов интернета, что
позволяет сконцентрировать внимание.
Такой подход особенно полезен для тех, кто проводит большую часть дня за
экраном монитора, так как он обеспечивает отдых для глаз. Чтение бумажных
книг может повысить эффективность обучения за счет сокращения «цифро-
вой усталости» и полного погружения в материал.
В Kindle доступны миллионы электронных книг, которые можно читать
когда и где угодно. Такие платформы аудиокниг, как Audible и Google Play,
предоставляют возможность слушать книги во время поездок. Нам доступно
так много удобных ресурсов, что отказу от непрерывного обучения просто
нет оправдания.
Обучение в интернете стало революцией. Оно позволяет легко понять и глу-
боко изучить любую область. У вас под рукой находятся огромные объемы
данных, по которым можно изучать что угодно. Такие интернет-платформы,
как Udemy или Coursera, предоставляют тысячи учебных видеороликов по
всем темам; их можно смотреть в интернете или загружать на устройство для
автономного просмотра.
• Будьте в курсе технологических новостей, читая статьи на сайтах и в бло-
гах: лучший способ не отставать от технологических достижений — под-
писка на технические новости и блоги. TechCrunch.com, Wired.com и Cnet.
com — популярные сайты, на которых вы найдете актуальную информацию
о технологических новинках. Крупные газеты CNBC, The New York Times,
каналы BBC News и CNN также публикуют статьи с полезной информацией
об отраслевых тенденциях. Чтобы быть в курсе полезной информации в со-
ответствующих технологических областях, можно подписаться на блоги.
Развитие благодаря непрерывному обучению 637
Например, в изучении облачных платформ помогут блоги AWS (Amazon
Web Services) с тысячами статей и примеров использования облака AWS;
аналогичные блоги существуют и для других публичных облачных платформ,
включая Azure и GCP (Google Cloud Platform).
• Пишите посты в блогах, статьи или книги: делиться знаниями — лучший
способ чему-то научиться, так как, рассказывая о своем опыте другим, вы
тщательно продумываете возможные сценарии использования. Публикация
блогов и статей на популярных платформах — Medium, Blogger, LinkedIn —
помогает распространять знания и учиться у других. Активно участвуя
в работе платформ вопросов/ответов, вы сможете находить альтернативные
решения для любых задач. Некоторые популярные платформы вопросов/
ответов — Quora, Reddit, Stack Overlow и Stack Exchange.
• Укрепляйте свои знания, обучая других: в процессе обучения вы общаетесь
с другими людьми и получаете возможность взглянуть на свои знания под новым
углом. Сценарии использования, предлагаемые участниками, часто содержат
новые пути решения. Проводя семинары с практической частью и формирова-
нием концепций, вы сможете укрепить свои знания и научить других.
• Учитесь в интернете: иногда формальное обучение требует слишком жест-
кой дисциплины, а вам нужно больше гибкости. Учебные курсы в интернете
обеспечивают гибкость, помогают скорректировать приоритеты и сэкономить
время. Они предоставляют организованные средства изучения новых техно-
логий и расширения знаний.
• Учитесь у коллег: коллеги работают в одной среде с вами, и вы проводите
большую часть своего рабочего времени с ними. Общение с коллегами может
ускорить обучение. Команда может применять стратегию, когда участники
рассказывают о своих темах и проводят учебные семинары за обедом. Каждый
участник еженедельно делится новыми знаниями, и все остальные быстро
их осваивают.
• Посещайте и участвуйте в работе пользовательских групп и конференций:
все крупные промышленные и технологические организации проводят конфе-
ренции и практические семинары для распространения информации о новых
технологических тенденциях. Участие в отраслевых конференциях и встречах
способствует развитию нетворкинга и пониманию технологических тенден-
ций. Среди крупных конференций от отраслевых лидеров можно упомянуть
AWS re:Invent, Google Cloud Next, Microsoft Ignite, SAP SAPPHIRE и Strata
Data Conference. Также можно создать локальную группу пользователей
и организовать встречу в вашем регионе, чтобы наладить сотрудничество
с профессионалами из других отраслей и организаций.
Непрерывное профессиональное развитие исключительно важно для архитекто-
ра решений. Стремительное развитие технологии обязывает к периодическому
обновлению сертификатов и удостоверений, чтобы не отставать от новых до-
стижений и отраслевых стандартов.
638 Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Архитектор решений играет роль технологического лидера, а хороший лидер
должен готовить других лидеров. Для этого существует система наставничества
(менторства). В следующем разделе роль ментора рассматривается более подробно.
Роль ментора
В качестве ментора вы помогаете другим и готовите их к успеху, руководствуясь
своим опытом. Это эффективный способ подготовки лидеров на основе инди-
видуального взаимодействия ментора с ментй (учеником).
Чтобы быть хорошим наставником, необходимо выработать неформальный стиль
общения, при котором ученик будет чувствовать себя комфортно. Ученик может
задавать вопросы из разных областей — например, касающиеся карьерного разви-
тия или личных вопросов (таких, как баланс работы и личной жизни). Проведите
неформальную оценку потребностей и определите взаимные цели и ожидания.
Ментор должен больше слушать, чем говорить. Иногда людям нужно, чтобы их
кто-то выслушал и дал полезный совет. Всегда внимательно слушайте ученика
и поймите его точку зрения.
Помогите ученику принимать самостоятельные решения, чтобы он ощущал, что
делает что-то своими силами. Давая советы по карьерному росту, хороший ментор
должен следить, чтобы они соответствовали интересам ученика, даже если они
неидеальны для компании. Всегда предоставляйте честную, конструктивную
обратную связь, чтобы помочь ученикам выявлять и преодолевать препятствия.
Важнейшее качество ментора — умение вдохновлять других. Часто люди вы-
бирают кого-то наставником, если они видят в нем образец для подражания.
Помогите своим ученикам раскрыть их потенциал и добиться того, о чем они
даже не догадывались. Роль ментора всегда приносит обоюдную пользу; вы
также узнаете от своих учеников что-то новое о поведении людей и их профес-
сиональном росте. Наставничество в конечном счете поможет вам стать лучше
и как руководителю, и как человеку.
Чтобы перевести свой опыт на новый уровень, вы можете стать технологическим
евангелистом и лидером мнений. Эта тема рассматривается в следующем разделе.
Роль технологического евангелиста
и лидера мнений
Технологический евангелист — это эксперт, продвигающий использование
определенной технологии и продукта. В некоторых организациях с широкой
базой продуктов существует отдельная должность технологического еванге-
листа. Однако часто эту роль берет на себя архитектор решения. Евангелист
должен разбираться в текущих технологических тенденциях, чтобы понимать
реальные проблемы и выступать за применение продвигаемой технологии для
удовлетворения интересов бизнеса.
Итоги 639
Технологический евангелист участвует в отраслевых конференциях в качестве
докладчика и продвигает свою платформу. Это позволяет ему стать авторитетным
экспертом и лидером мнений, что может способствовать росту популярности
платформы и продукта. Навык публичных выступлений — один из важнейших
навыков архитектора решений, потому что ему приходится общаться на разных
открытых платформах и в больших аудиториях.
Евангелист также пишет и публикует статьи и посты в блогах и ведет микро -
блоги для продвижения своего продукта. Он распространяет информацию для
повышения лояльности к продукту и общается с пользователями, чтобы полу-
чать обратную связь. Затем он передает ее внутренней команде, чтобы улучшить
продукт. Со временем вы, как евангелист, сможете более четко формулировать
месседж, наиболее эффективно продвигающий интересы организации.
Роль архитектора решений подразумевает набор разнообразных обязанностей,
и дополнительная ответственность будет способствовать успеху вашей карьеры.
Итоги
В этой главе рассматривались гибкие навыки, необходимые для успешной
работы архитектора решений, и их важность. Архитектору решений требуются
навыки предварительных продаж, которые помогут ему обеспечить поддержку
предпродажного цикла организации — например, с помощью RFP.
Вы узнали о навыках представления информации, необходимых для общения
с руководством и получения одобрения, и стратегическом мышлении, которым
должен обладать архитектор решений, чтобы определять для организации ключе-
вые цели и результаты. Чтобы работать на разных уровнях, архитектор решений
должен мыслить масштабно, быть гибким и уметь адаптироваться. В этой главе
было рассказано о том, как архитекторы решений принимают на себя владение
своими действиями и ответственность за результат
Основная обязанность архитектора решений — проектирование архитектуры.
Вы узнали о дизайн-мышлении, его принципах и составляющих. Также мы рас-
смотрели важность непрерывного обучения и приемы, позволяющие оставаться
в курсе новейших тенденций рынка. Мы изучили дополнительные обязанности
архитектора решений — роли ментора и евангелиста.
Мы прошли большой путь. Вы узнали об архитекторах решений все: от их ролей
и обязанностей до параметров проектирования решений и оптимизации архитек-
тур. Надеюсь, полученные знания помогут вам построить карьеру архитектора
решений или добиться успеха в текущей должности.
Счастливого обучения!
г ч
Read
к______J
IT Club
Комьюнити рецензентов
и переводчиков ИТ-литературы
Миссия участников клуба — обеспечить
высокое качество профессиональной
переводной литературы в России.
«Книжные дебагеры» проверяют
корректность терминологии и подписей
на схемах и иллюстрациях, чтобы сделать
книги более понятными русскоязычному
читателю. Стать участником Read IT Club
может любой ИТ-специалист, готовый
поделиться опытом с сообществом.