/
Автор: Шривастава С. Шривастав Н.
Теги: система управления базами данных (субд) архитектура вычислительных машин информационные машины машины для обработки данных вычислительные машины и устройства дискретного действия (цифровые вычислительные машины и устройства) информационные технологии машинное обучение информационные системы цифровые технологии
ISBN: 978-601-12-3976-9
Год: 2025
Текст
Solutions Architect’s Handbook
Third Edition
Kick-start your career with architecture design principles,
strategies, and generative AI techniques
Saurabh Shrivastava
Neelanjali Srivastav
Solutions architect
Третье издание
Архитектура и проектирование
ИТ-решений
Саурабх Шривастава
Ниланджали Шривастав
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-ФЗ.)
© Packt Publishing 2024.
First published in the English language under the title ‘Solutions
Architect’s Handbook - Third Edition – (9781835084236)’
ISBN 978-601-12-3976-9
© Перевод на русский язык ТОО «Спринт Бук», 2025
© Издание на русском языке, оформление ТОО «Спринт Бук», 2025
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без
письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные.
Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать
абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные
с использованием книги.
Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге.
На момент подготовки книги к изданию все ссылки на интернет-ресурсы были действующими.
Изготовлено в России. Изготовитель: ТОО «Спринт Бук». Место нахождения и фактический адрес:
010000, Казахстан, город Астана, район Алматы, проспект Ракымжан Кошкарбаев, дом 10/1, н. п. 18.
Дата изготовления: 11.2025. Наименование: книжная продукция. Срок годности: не ограничен.
Подписано в печать 26.09.25. Формат 70×100/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
Построение n-уровневой архитектуры............................................................ 153
Веб-уровень............................................................................................................... 154
Уровень приложения............................................................................................. 154
Уровень базы данных............................................................................................. 155
Создание мультитенантной архитектуры на базе SaaS . ................................ 156
Сервис-ориентированная архитектура.................................................................. 158
RESTful-архитектура............................................................................................. 159
Создание сайта интернет-магазина на базе RESTful-архитектуры............. 161
Построение архитектуры на базе кэша............................................................ 163
Паттерн Cashe distribution (Распределенное кэширование)
в трехуровневой веб-архитектуре...................................................................... 166
Паттерн Rename distribution (Распределение с переименованием)...... 167
Паттерн Cache proxy (Кэширующий прокси-сервер)................................ 168
Паттерн Rewrite proxy (Заменяющий прокси-сервер).............................. 169
Паттерн App caching (Кэширование на уровне приложения)................. 171
Memcached и Redis.................................................................................................. 172
Архитектура MVC (Model-View-Controller)....................................................... 173
Применение MVC при проектировании книжного .
интернет-магазина................................................................................................... 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
A/B-тестирование................................................................................................... 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 и AWS Backup
Третье издание книги «Solutions architect: архитектура и проектирование ИТрешений» было опубликовано в критический момент, когда пандемия COVID-19
ускорила цифровую трансформацию и внедрение облачных технологий. Книга
как нельзя вовремя отвечает на острую потребность в архитекторах решений
для перехода на облачно-ориентированные архитектуры и микросервисы. Вы
найдете в ней важнейшие рекомендации по масштабированию, операционной
устойчивости, аварийному восстановлению и непрерывности бизнеса. Книга
предоставляет перспективную точку зрения на разработку распределенных приложений и стремительное распространение облачно-ориентированных решений,
отражая сдвиг парадигмы в технологических архитектурах.
Издание, в котором рассматриваются настолько разнообразные темы, от облачной миграции и модернизации до передовых направлений машинного обучения
и генеративного ИИ, станет бесценным ресурсом для многих архитекторов.
Книга мастерски связывает вопросы модернизации унаследованных (легаси)
систем, включая факторы использования мейнфреймов, с новейшими фундаментальными моделями и инструментами генеративного ИИ и отличается
глубоким рассмотрением тенденций, формирующих будущее архитектурного
проектирования.
«Solutions architect: архитектура и проектирование ИТ-решений» выделяется
целостностью подхода. В ней рассматривается широкий спектр важных тем —
от функциональных архитектур и интеграции до расширяемости, возможности
повторного использования, юзабилити, доступности, управления затратами
и безопасности. Широта рассматриваемых вопросов и практических советов
делает ее бесценным источником информации как для начинающих, так и для
20 Предисловие
опытных архитекторов, желающих сориентироваться в сложностях современных облачно-центричных сред. Книга Саурабха и Ниланджали, основанная на
их богатом опыте, укажет верное направление всем, кто хочет добиться успеха
в стремительно развивающейся сфере архитектур решений.
Рохан Кармаркар (Rohan Karmarkar),
директор по архитектуре решений, AWS
Технологии всегда быстро движутся вперед, и чтобы преуспеть в этой отрасли,
ИТ-профессионал должен постоянно приобретать новые навыки. За последнее десятилетие эта тенденция стала доминирующей, а облачные вычисления
превратились в «новую нормальность». Анонсы, новая функциональность
и обновления сервисов от облачных провайдеров появляются почти ежедневно,
что заставляет каждого, кто работает в ИТ-сфере, делать упор на непрерывное
обучение. Кроме того, начали размываться границы между привычными задачами
разработчика, администратора баз данных, специалиста по безопасности, билд/
релиз-инженера и т. д., что привело к созданию новых ролей, в центре внимания
которых — общая картина и сквозная ответственность. Одной из таковых стала
роль архитектора решений; она начала развиваться на базе существующих ролей
в отрасли (например, архитектора приложений и ИТ-архитектора) и сейчас
активно завоевывает популярность. У этой роли существуют разновидности;
тем не менее самым частым ее воплощением остается весьма динамичная роль
архитектора облачных решений.
ИТ-специалисты нередко хотят сменить роль, но им не хватает руководства, как
добиться успеха на этом пути. Книга фокусируется именно на этом аспекте —
успешном переходе с существующей ИТ-роли на роль архитектора решений.
В ней последовательно объясняются шаги, которые необходимо пройти на этом
пути. Сначала дается простое и понятное объяснение того, что означает роль
архитектора решений и чем она отличается от других схожих профилей. Затем
рассматриваются технические навыки и знания, необходимые для успешной работы архитектором решений. Объясняются базовые принципы проектирования
архитектуры (такие как высокая доступность, надежность, производительность,
безопасность и оптимизация затрат), после чего следует углубление в каждый
из этих аспектов. Книга также охватывает ключевые концепции, связанные
с облачно-ориентированными архитектурами, DevOps, а также инженерией
данных и машинным обучением, которые являются краеугольным камнем любой
современной архитектуры. В последней редакции книги Саурабх и Ниланджали
также добавили весьма содержательные детали по облачно-ориентированным
архитектурам, генеративному ИИ, глубокому обучению, CloudOps, расширенной
аналитике и миграции в облако. Все эти области постепенно становятся ключевыми для корпоративного ИТ-ландшафта, и архитекторам решений крайне важно
быть в курсе современных трендов, чтобы всегда оказываться на шаг впереди.
Предисловие
21
Вместе с Саурабхом я прошел путь от тимлида разработчиков до архитектора
решений. В то время нам очень хотелось иметь руководство, которое бы нам
помогло, но его не было. И чтобы восполнить этот пробел, Саурабх написал
чрезвычайно подробную книгу, основанную на личном опыте и полученных
знаниях, благодаря которым она получилась доступной для всех. Я настоятельно рекомендую прочесть ее и держать под рукой — вы найдете в ней ценную
информацию, которая поможет вам стать успешным архитектором решений
и откроет новый мир бесконечных возможностей!
Камаль Арора (Kamal Arora),
директор по архитектуре решений, AWS
https://www.amazon.com/Kamal-Arora/e/B07HLTSNRJ/
СОЗДАТЕЛИ КНИГИ
Об авторах
Саурабх Шривастава — технологический лидер, автор, изобретатель и спикер
с более чем 20-летним опытом работы в ИТ-отрасли. В настоящее время он
занимает должность руководящего архитектора глобальных решений в AWS
(Amazon Web Services), помогая партнерам AWS и клиентам осуществить переход к облачной платформе. Саурабх возглавлял глобальные технологические
партнерства AWS, определял вˆидение и рабочую модель своей команды, а также
внедрил ряд новых стратегических инициатив.
Кроме своей работы в AWS, Саурабх является автором популярной книги издательства Packt «AWS for Solutions Architects, Second edition», ведет блоги
и пишет статьи, посвященные различным технологиям: big data, IoT, машинному
обучению, облачным вычислениям и др. Он является большим энтузиастом
инноваций и их влияния на общество и повседневную жизнь. Саурабх владеет
несколькими патентами в области автоматизации облачных платформ. Он
работал архитектором корпоративных решений, архитектором программного
обеспечения, а также руководил разработками в компаниях из списка Fortune 50,
стартапах и глобальных организациях, занимающихся разработками и консультированием. Благодаря огромному опыту и квалификации Саурабха его
книги являются ценным источником информации для всех, кто захочет больше
узнать об облачных вычислениях и их возможном применении.
Ниланджали Шривастав приобрела обширные знания благодаря богатому опыту
работы в качестве технологического лидера, продакт-менеджера и agile-тренера.
В настоящее время она является лидером портфеля технических проектов в Aya
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) и инфраструктуру как код
(IaC). Он прошел сертификацию 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, пользовательский ввод, идентификаторы. Например, «платформы IoT должны
поддерживать SigV4, X.509 и специальную аутентификацию, предоставляя
детализированное управление доступом с политиками IoT до уровня тем
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 рассматриваются смысл архитектуры решений и ее важность
как основы для разработки решений в организациях. Архитектура решений
подразумевает проектирование мощной основы, включающей такие важные
области, как ИТ-инфраструктура, безопасность приложений, надежность и вопросы эксплуатации.
Архитекторы решений работают в тесном контакте со стейкхолдерами проекта,
анализируя требования и прорабатывая ограничения в части затрат, бюджета,
сроков и комплаенса для создания полноценного решения.
Архитекторы решений также осуществляют активную поддержку продукта
после его выпуска, работая над обеспечением масштабируемости, доступности
и удобства обслуживания. Кроме того, они сотрудничают с отделом продаж для
продвижения продукта и его технических преимуществ.
y
y
y
y
y
y
y
y
y
y
y
y
В этой главе рассматриваются следующие темы.
Что такое архитектура решений?
Роль архитектора решений.
Обязанности архитектора решений.
Архитекторы решений в agile-организациях.
Типичные проблемы, с которыми сталкивается архитектор решений.
Карьерный путь и развитие навыков архитекторов решений.
К концу этой главы вы получите ценную информацию о роли архитекторов
решений и вызовах, с которыми они сталкиваются. Вы узнаете, как архитекторы решений справляются с ограничениями и вносят свой вклад в техническое
видение и общий успех своей организации.
30
Глава 1. Архитекторы решений в организациях
Что такое архитектура решения?
Представление об архитектуре решения может различаться в зависимости от
точки зрения, принятой конкретными профессионалами или организациями.
Тем не менее по своей сути архитектура решения подразумевает определение
и планирование различных аспектов бизнес-решения с учетом стратегических
и тактических факторов.
Со стратегической точки зрения архитектор решений отвечает за разработку
долгосрочного вˆидения. Оно гарантирует, что решение (программное обеспечение) останется актуальным и сможет адаптироваться к будущим изменениям,
с возможностью расширения в соответствии с изменяющимися требованиями
пользователей и рабочей нагрузкой.
С тактической точки зрения архитектура решения концентрируется на непосредственных потребностях бизнеса. Она ориентирована на проектирование
приложения, способного справиться с текущей рабочей нагрузкой и эффективно
решать повседневные задачи организации.
Тем не менее архитектура решения — это не просто код. Она охватывает всю
систему, включая такие области, как системная инфраструктура, сеть, безопасность, требования комплаенса, эксплуатация системы, вопросы издержек
и надежность.
С учетом всех этих вопросов архитектор решений создает подробный план,
который направляет разработку и реализацию решения. План не только обес
печивает удовлетворение текущих потребностей бизнеса, но и закладывает
основу для дальнейшего роста и успеха.
Преимущество архитектуры решения
Архитектура решения чрезвычайно важна по нескольким причинам. Прежде
всего она обеспечивает прочную основу для разработки корпоративных программных решений. По мере того как проекты разрастаются, а команды распределяются географически, наличие четко определенной архитектуры решения
гарантирует сохранение устойчивости и эффективности совместной работы
в долгосрочной перспективе.
Архитектура решения удовлетворяет разнообразные потребности решения с сохранением ориентации на общий бизнес-контекст. Она включает такие критические элементы, как технологические платформы, компоненты приложений,
требования к данным, потребности в ресурсах и важнейшие нефункциональные
требования, или НФТ (или NFR, non-functional requirements). К числу НФТ
относятся масштабируемость, надежность, производительность, доступность,
безопасность и удобство обслуживания. При соблюдении этих требований архитектура решения гарантирует, что разработанное решение будет удовлетворять
необходимым стандартам и ожиданиям.
Что такое архитектура решения?
31
На рис. 1.1 показаны потенциальные преимущества, которые получает
организация от участия архитектора решений в бизнесе.
Упрощение эффективной
совместной работы
Минимизация срыва
целевых сроков
Масштабируемость
и гибкость
Оценка
потенциала рынка
Соответствие технологии
бизнес-требованиям
Архитектура
решения
Определение сроков
проекта
Повышение окупаемости
инвестиций
Соответствие бизнес-целям
Улучшенное
планирование
ресурсов
Улучшенное
прогнозирование бюджета
Снижение рисков
Рис. 1.1. Преимущества архитектуры решения
На этой диаграмме выделены следующие преимущества хорошей архитектуры
решения.
y
y Соответствие технологии бизнес-требованиям: архитектор решений оце-
y
y
y
нивает, какие технологии следует внедрить в организацию или проект для
удовлетворения бизнес-требований и обеспечения устойчивости, удобства
обслуживания и необходимой квалификации команды в долгосрочной перспективе.
y Оценка потенциала рынка: архитектура решения включает процесс анализа
и непрерывной оценки последних тенденций рынка, чтобы гарантировать,
что разработанное решение удовлетворяет потребности клиента и бизнеса.
Она также помогает создавать и продвигать новые продукты.
y Минимизация срыва целевых сроков: архитектор решений непрерывно
работает со всеми стейкхолдерами (ключевыми заинтересованными лицами), включая бизнес-команду, клиентов и команду разработки. Он следит за
тем, чтобы общее решение соответствовало бизнес-целям и плану-графику
запуска и вероятность срыва целевых сроков была минимальной.
y Упрощение эффективной совместной работы: архитектура решения служит
общим ориентиром и инструментом взаимодействий для всех стейкхолдеров
y
y
y
y
y
y
y
y
y
y
y
y
32
Глава 1. Архитекторы решений в организациях
проекта. Она упрощает эффективную совместную работу бизнес-команд,
разработчиков, проектировщиков и других ключевых участников. Понятная
документация и наглядность архитектуры решения способствуют лучшему
пониманию, слаженности и организации принятия решений между членами
команды, гарантируя, что все одинаково понимают общие цели и работают
на их достижение.
Масштабируемость и гибкость: в хорошо спроектированной архитектуре
решения масштабирование и гибкость становятся ключевыми факторами.
Они позволяют решению адаптироваться и плавно расти по мере эволюции
бизнеса и увеличения пользовательских нагрузок. Архитектура решения,
способная прогнозировать будущий рост и нацеленная на реализацию мер
масштабируемости, гарантирует, что система справится с растущими потребностями без значительных перебоев в работе или дорогостоящих изменений.
Соответствие бизнес-целям: главной задачей проектирования архитектуры
решения являются удовлетворение потребностей стейкхолдеров и возможность адаптироваться к их требованиям. Архитектура решения преобразует бизнес-цели в техническое вˆидение посредством анализа рыночных
тенденций и реализации лучших практик. Архитектура решения должна
быть достаточно гибкой, чтобы соответствовать новым, нетривиальным
и стремительно изменяющимся бизнес-требованиям.
Улучшенное планирование ресурсов: имея четко определенную архитектуру решения, организации могут точно определить тип и количество необходимых ресурсов. Тем самым облегчается стратегическое планирование
человеческих ресурсов, обеспечивается достаточное финансирование и время
работы, гарантируется наличие специалистов необходимой квалификации
и оптимальное использование ресурсов, что ведет к более плавному ходу
проекта и соблюдению сроков.
Улучшенное прогнозирование бюджета: для эффективного прогнозирования
бюджета крайне важно осуществлять тщательную оценку и анализ. Хорошо определенная структура решения предоставляет понятную, доступную
информацию о том, какие ресурсы необходимы для завершения проекта.
Понимание деталей масштаба и требований позволяет организациям точнее
прогнозировать затраты и сокращает риск перерасхода бюджета.
Снижение рисков: хорошая архитектура решения включает оценку рисков
и стратегии их снижения. За счет выявления потенциальных рисков на
более ранней стадии архитекторы решений могут реализовать меры, чтобы снизить риски или избежать их. Такой проактивный подход помогает
свести к минимуму риски для графика проекта, бюджета и общего успеха.
Стратегии снижения рисков могут включать планы резервного копирования,
меры создания избыточности, факторы безопасности и планы аварийного
восстановления.
Повышение окупаемости инвестиций: архитектура решения определяет
окупаемость и помогает оценить успех проекта. Она мотивирует бизнес
Роль архитектора решений
33
y
думать о способах сократить затраты и устранить потери за счет применения
автоматизации, что повышает общую окупаемость инвестиций.
y Определение сроков проекта: определение точных сроков проекта чрезвычайно важно для реализации решения. Архитектор решений выявляет,
какие ресурсы и усилия потребуются на этапе проектирования, что должно помочь установить количество времени, необходимое для разработки
решений.
Итак, теперь у вас имеется общее представление об архитектуре решения и ее
преимуществах. Перейдем к рассмотрению роли архитектора решений и ее
влиянию на построение качественной архитектуры решения.
Роль архитектора решений
Если вас интересуют способы надлежащей организации и поставки решения,
знайте: архитектор решений играет важнейшую роль в их определении. Он
проектирует систему в целом и интеграцию разных систем между разными
группами. Архитектор решений определяет ожидаемый результат, работая
с бизнес-стейкхолдерами и обеспечивая четкое понимание технической командой целей поставки.
На рис. 1.2 представлена блок-схема жизненного цикла поставки решения. Архитектор решений участвует во всех этапах проектирования и поставки решения.
Требования
и видение
бизнеса
Анализ
требований
и техническое
видение
Прототипирование и рекомендации
Проектирование
решения
Эксплуатация и обслуживание
Реализация
Интеграция
и тестирование
Разработка
Рис. 1.2. Жизненный цикл поставки решения
Как показано на диаграмме, жизненный цикл поставки решения включает следующие этапы с участием архитектора решения.
y
y Требования и вˆидение бизнеса: архитектор решений работает с бизнесстейкхолдерами, чтобы понять их вˆидение.
34
Глава 1. Архитекторы решений в организациях
y
y
y
y
y
y
y
y
y
y
y
y
y
y Анализ требований и техническое вˆидение: анализ требований, определя-
ющий техническое вˆидение для исполнения бизнес-стратегии.
Прототипирование и рекомендации: архитектор решений выбирает технологию, проводя проверку концепции (POC, proof of concept) и демонстрируя
прототипы.
Проектирование решения: архитектор решений разрабатывает решения
в соответствии со стандартами организации и в сотрудничестве с другими
заинтересованными группами.
Разработка: архитектор работает с командой разработчиков над созданием
решения. Он становится связующим звеном между бизнесом и техническими
командами.
Интеграция и тестирование: архитектор проверяет, что итоговое решение
работает в соответствии со всеми функциональными и нефункциональными
требованиями.
Реализация: архитектор сотрудничает с командами разработки и развертывания для создания беспроблемной реализации и помогает им справиться
со всеми возникающими сложностями.
Эксплуатация и обслуживание: архитектор проверяет, что средства ведения
журналов и мониторинга функционируют, и по мере необходимости направляет работу команды по масштабированию и восстановлению после сбоев.
Общий жизненный цикл является итеративным процессом. Когда приложение
перейдет на продакшен и им начнут пользоваться, на основании обратной связи
от заказчиков могут возникнуть новые требования, которые отразятся на вˆидении
будущих усовершенствований продукта.
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Архитектор решений несет ответственность за решение следующих задач на
этапе проектирования:
документирование стандартов решения;
определение высокоуровневого дизайна решения;
определение межсистемной интеграции;
определение фаз решения;
определение подхода к реализации;
определение способа мониторинга и оповещений;
документирование сильных и слабых сторон дизайна решения;
документирование требований аудита и комплаенса.
Архитекторы решений не только отвечают за проектирование решения, но
и помогают руководителям проектов с оценкой ресурсов и издержек, определением сроков проекта и основных контрольных точек, а также релизом проекта
и составлением плана поддержки. Архитектор решений прорабатывает разные
фазы жизненного цикла решения, от проектирования до поставки и запуска.
Роль архитектора решений
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. Архитекторы решений в организациях
предоставляя аналитику и рекомендации по принятию технологий, архитектурным решениям и инициативам цифровой трансформации в отрасли.
Используя свой опыт в отрасли и знания архитектуры, отраслевой архитектор
способствует росту, эффективности и цифровой трансформации организаций,
работающих в конкретных секторах. Он играет ключевую роль в обеспечении
соответствия технологических решений отраслевым стандартам, нормам, правилам и лучшим практикам, что в конечном счете способствует внедрению
инноваций и успеху в отрасли.
Несколько примеров отраслевых архитекторов в конкретных секторах.
y
y Отраслевой архитектор в области финансов: специализируется на техноло-
y
y
y
гических решениях для финансовых учреждений, понимании сложных норм
и стандартов и потребностей в безопасности. Он разрабатывает решения для
управления рисками, обнаружения мошенничества и обеспечения комплаенса
в финансовом секторе.
y Отраслевой архитектор в производстве: проектирует решения для производственных секторов (например, автомобильной промышленности или
производства потребительских товаров), уделяя первоочередное внимание
оптимизации цепочек поставок, планированию производства и промышленному интернету вещей для повышения эффективности и производительности.
y Отраслевой архитектор в розничной торговле: разрабатывает технологические решения для розничной торговли, включая POS-системы, CRM
и омниканальные взаимодействия. Первоочередное внимание уделяет
безопасности данных, а также интеграции физических и цифровых каналов
розничной торговли.
y Отраслевой архитектор в области здравоохранения: занимается разработкой
решений в сфере медицины, проектируя системы для ведения электронных
медицинских карт, управления пациентами и телемедицины. Решает проблемы конфиденциальности, безопасности и комплаенса в области здравоохранения.
Мы рассмотрели лишь некоторые примеры отраслевых архитекторов и секторов,
в которых они специализируются. В каждой отрасли существуют уникальные
проблемы, требования и технологическая среда, и отраслевые архитекторы
играют важную роль в проектировании специализированных решений, удо
влетворяющих специфические потребности этой отрасли.
Роль SSA выходит за рамки отраслей и технологических предметных областей.
В нее входят конкретные поставщики SaaS — такие, как Salesforce, ServiceNow,
Databricks и Snowflake, а также корпоративные приложения от SAP, VMware,
Microsoft, Oracle и таких облачных платформ, как AWS, GCP и Azure. Рас
смотреть все возможные роли SSA в одном разделе достаточно сложно, поэтому
Обязанности архитектора решений
49
мы сосредоточились на общей концепции роли, подчеркивая ее разнообразие
и широкий спектр специализаций в этой области.
После знакомства с разнообразием ролей архитекторов решений перейдем
к рассмотрению их обязанностей.
Обязанности архитектора решений
Архитектор решений является техническим руководителем, взаимодействующим
с заказчиком, что обусловливает наличие у него широкого круга обязанностей.
Главная обязанность архитектора решений — преобразование бизнес-видения
организации в техническое решение и создание связи между стейкхолдерами из
сфер бизнеса и технологий. Архитектор решений использует обширный технологический и коммерческий опыт, чтобы обеспечить успешную поставку решения.
Обязанности архитектора решений могут несколько отличаться в зависимости
от природы организации. В организациях, занимающихся консультированием,
архитектор решений часто выделяется под конкретный проект и заказчика,
тогда как в организациях, занимающихся созданием продуктов, архитектор
решений может работать с несколькими заказчиками, обучая их продукту
и оценивая дизайн их решений.
Архитектор решений имеет разные обязанности на разных стадиях цикла разработки приложения, даже еще до запуска проекта. В фазе предварительного
планирования проекта архитектор решений работает с бизнес-стейкхолдерами
для подготовки и оценки документа RFR (Request For Response) (запрос на
решение).
После запуска проекта архитектор решений анализирует требования, чтобы
принять решение о возможности его технической реализации, одновременно
определяя такие нефункциональные требования (НФТ), как масштабируемость,
высокая доступность, производительность и безопасность. Архитектор решений
понимает различные ограничения проекта и выбирает технологию, разрабатывая
подтверждения концепции (POC, Proof Of Concept).
После начала разработки архитектор решений выполняет функции наставника
команды разработки и корректирует как технические, так и бизнес-потребности.
После запуска приложения архитектор решений проверяет, что оно работает
в соответствии с заданными НФТ, и определяет следующую итерацию на основании обратной связи от пользователей.
В этом разделе вы больше узнаете о роли архитектора решений на разных
стадиях жизненного цикла разработки продукта. В целом архитектор решений
выполняет обязанности, представленные на рис. 1.3.
50
Глава 1. Архитекторы решений в организациях
Анализ
функциональных
требований
Масштабирование решения,
технологический
евангелист
Проектирование
и поставка
решения
Определение
нефункциональных
требований
Понимание
и вовлечение
стейкхолдеров
Обязанности архитектора
решений
Понимание
ограничений
архитектуры
Разработка PoC
и прототипа
Выбор
технологии
Рис. 1.3. Модель обязанностей архитектора решений
Как видно из схемы, архитектор решений имеет множество обязанностей. В следующих разделах они рассматриваются подробнее.
Анализ функциональных требований (ФТ)
На начальной стадии любого проекта определение бизнес-требований становится важнейшим основанием для дизайна решения. Их первичное базовое
представление обусловливает необходимость привлечения разносторонней
команды, включая участников с техническим опытом, с тем чтобы в точности
определить и понять эти требования. Изначально требования устанавливаются
бизнес-стейкхолдерами. По мере технологического развития проекта часто возникает необходимость в их корректировке. В таких ситуациях роль архитектора
решений выходит на первый план не только в отношении проектирования приложения, но и в формировании общего бизнес-результата.
Архитекторы решений не ограничиваются техническими знаниями; они используют глубокое понимание бизнеса и добиваются того, чтобы технология
Обязанности архитектора решений
51
соответствовала целям бизнеса. Они тесно взаимодействуют с руководителями
проектов и стейкхолдерами, связывая функциональные требования (ФТ) с техническими решениями и выступая доверенными консультантами. Они играют
ключевую роль в вˆидении конечного продукта и его реализации и направляют
проект так, чтобы он не только соответствовал техническим спецификациям,
но и отвечал стратегическим целям бизнеса и удовлетворял ожидания пользователей.
По сути роль архитектора решений не ограничивается традиционными рамками
технических знаний. Он помогает ликвидировать разрыв между техническими
возможностями и реалиями бизнеса, стремясь, чтобы итоговое решение не
только соответствовало техническим спецификациям, но и приносило реальную
ценность для бизнеса. Умение архитектора решений работать с различными
стейкхолдерами, понимать тонкости потребностей бизнеса и предвидеть потенциальные проблемы делает его незаменимым проводником на пути от концепции
до реализации проекта. Успех проекта часто зависит от умения архитектора
решений преобразовывать сложные требования в связную, функциональную
и эффективную архитектуру решения.
Функциональные требования (ФТ) указывают, что должна делать система,
с подробным описанием поведения, функций и возможностей, которые должно
поддерживать приложение. Они напрямую относятся к взаимодействию с пользователями и задачам, которые будет выполнять приложение.
Нефункциональные требования (НФТ) определяют, как система должна выполнять некоторые функции, задают атрибуты качества системы (такие, как
производительность, удобство использования, надежность и безопасность). Эти
требования описывают условия эксплуатации системы и ограничения, влияющие на опыт взаимодействия с пользователями, но не на конкретное поведение.
Давайте познакомимся с НФТ поближе и посмотрим, как архитекторы решений
помогают их определить.
Определение НФТ
НФТ не всегда видны пользователям и заказчикам непосредственно, но их
отсутствие может отрицательно повлиять на общий опыт взаимодействия
с пользователями и навредить бизнесу. НФТ включают такие критические характеристики системы, как производительность, задержка, масштабируемость,
высокая доступность и восстановление при аварийных ситуациях. Наиболее
распространенные НФТ представлены на рис. 1.4.
Для определения НФТ архитекторы решений отвечают на следующие вопросы.
y
y Производительность:
Каким будет время загрузки приложения для пользователей?
Как решить проблему сетевой задержки?
52
Глава 1. Архитекторы решений в организациях
y
y
y
y
y Безопасность и комплаенс:
Как защитить приложение от несанкционированного доступа?
Как защитить приложение от атак злоумышленников?
Как обеспечить соблюдение местных законов и требований аудита?
y Восстанавливаемость:
Как восстановить приложение в случае сбоя?
Как свести к минимуму время восстановления в случае сбоя?
Как восстановить потерянные данные?
y Удобство обслуживания:
Как организовать мониторинг и выдачу оповещений в приложении?
Как обеспечить поддержку приложения?
y Надежность:
Как убедиться в согласованности поведения приложения?
Как обнаруживать и исправлять дефекты?
Производительность
Удобство
использования
Безопасность
и комплаенс
Нефункциональные
требования
Масштабируемость
Восстанавливаемость
Удобство
обслуживания
Доступность
Надежность
Рис. 1.4. НФТ в дизайне решения
Обязанности архитектора решений
53
y
y
y
y Доступность:
Как обеспечить высокую доступность приложения?
Как обеспечить отказоустойчивость приложения?
y Масштабируемость:
Как удовлетворить повышенную потребность в ресурсах?
Как обеспечить масштабирование при непредвиденном скачке нагрузки?
y Удобство использования:
Как упростить работу с приложением?
Как обеспечить бесперебойный пользовательский опыт?
Как сделать приложение доступным для разных групп пользователей?
В зависимости от природы проекта некоторые НФТ могут быть актуальны
только для конкретного проекта (например, четкая различимость голоса для
решений, предназначенных для контакт-центров).
Вы узнаете больше об этих характеристиках в главе 2 «Принципы проектирования архитектур решений».
Архитектор решений начинает участвовать в проекте на очень ранней стадии,
а это означает, что он должен спроектировать решение, собрав требования от
всех стейкхолдеров в организации. Архитектор решений должен обеспечить
согласованность дизайна решения между разными системными компонентами
и требованиями. Он отвечает за определение НФТ между разными компонентами и группами, поскольку должен обеспечить достижение желаемого удобства
использования по всем параметрам.
НФТ — неотъемлемая и существенная часть дизайна решения, которую нередко
упускают из виду, когда команды слишком сильно сосредоточены на бизнестребованиях, а это может отразиться на взаимодействии с пользователями.
Хороший архитектор решений должен донести важность НФТ и убедиться, что
их реализация включена в поставку решения.
Понимание и вовлечение стейкхолдеров
Ключевым заинтересованным лицом, или стейкхолдером, называется любое
лицо, заинтересованное в проекте (прямо или косвенно). Кроме заказчиков
и пользователей, стейкхолдерами также могут быть команды разработки,
продаж, маркетинга, инфраструктуры, сетей и поддержки, а также группа
финансирования проекта. Стейкхолдеры могут быть внутренними или внешними
по отношению к проекту. К внутренним относятся команда проекта, спонсоры,
сотрудники и старший менеджмент; к внешним — заказчики, поставщики, парт
неры, акционеры, аудиторы и действующее правительство страны.
Стейкхолдеры часто по-разному понимают одну и ту же бизнес-задачу в зависимости от контекста, в котором они находятся; например, разработчик может
54
Глава 1. Архитекторы решений в организациях
рассматривать бизнес-требование с точки зрения программирования, а аудитор — с позиций безопасности и комплаенса.
Чтобы обеспечить успех проекта, архитектор решений должен работать как
с техническими, так и с нетехническими стейкхолдерами. Он должен понимать
требования к проекту с разных точек зрения, вследствие чего ему приходится
общаться с разными группами. При этом ему приходится объяснять сложные
технические концепции для нетехнических стейкхолдеров и принимать меры
к тому, чтобы техническая команда понимала бизнес-цели. Сотрудничая со всеми
участвующими сторонами, архитектор решений следит за тем, чтобы техническое решение соответствовало более широким бизнес-целям. Такая совместная
работа крайне необходима для создания полноценного и эффективного решения,
удовлетворяющего потребности всех сторон.
Архитектор решений обладает превосходными навыками коммуникации
и ведения переговоров, что помогает ему выбрать оптимальный путь с учетом
всех остальных мнений. Архитектор решений выступает связующим звеном
между техническими и нетехническими специалистами и устраняет разрывы
в коммуникации между ними. Часто такие разрывы становятся причиной провала проекта. Представители бизнеса рассматривают ситуацию с точки зрения
функциональности и возможностей продукта, тогда как команда разработки
стремится построить как можно более технически совместимое решение, что
иногда затрагивает нефункциональную сторону проекта.
Архитектор решений должен убедиться в том, что обе команды находятся на
одной волне, а предлагаемая функциональность технически осуществима. Он
выполняет функции ментора для технической команды и по мере необходимости руководит ею, а также объясняет технические концепции простым языком,
понятным всем остальным.
Архитектурные ограничения
Архитектурные ограничения — одна из самых сложных составляющих дизайна
решений. Архитектурные ограничения значительно усложняют проектирование,
поскольку ограничивают гибкость и инновационность. Чтобы новые решения
оставались технически совместимыми с существующими системами в рамках
этих ограничений, потребуются немалые усилия и ресурсы. Кроме того, ограничения, относящиеся к бюджету, ресурсам и срокам, могут повлиять на качество
и масштаб решения. Поддерживать баланс между соблюдением отраслевых
стандартов и требований законодательства и реализацией функциональных
потребностей достаточно сложно.
Архитектор решений должен внимательно управлять архитектурными ограничениями и иметь возможность обсуждать их, чтобы найти оптимальное решение. Часто эти ограничения зависят друг от друга, и особое внимание к одному
ограничению может повысить важность других. Самые распространенные
ограничения представлены на рис. 1.5.
Обязанности архитектора решений
55
Качество
Затраты
Время
Архитектурные
ограничения
Комплаенс
Ресурс
Масштаб
Технология
Риск
Рис. 1.5. Архитектурные ограничения при дизайне решения
При проектировании решения должны учитываться следующие ограничения.
y
y
y
y
y Затраты:
Какой объем финансирования доступен для реализации решения?
Какая рентабельность предполагается?
y Качество:
Насколько близко результат соответствует ФТ и НФТ?
Как обеспечить и отслеживать качество решения?
y Время:
Когда должен быть поставлен результат?
Возможна ли корректировка срока поставки?
y Масштаб:
Каковы точные ожидания бизнеса и требования заказчика?
Как преодолеть разрыв в требованиях при проектировании?
56
Глава 1. Архитекторы решений в организациях
y
y Технология:
Какую технологию можно использовать?
Какую гибкость обеспечит использование унаследованных технологий
y
y
y
по сравнению с новыми?
Следует ли заниматься разработкой собственными силами или доверить
ее внешнему подрядчику?
y Риск:
Что может пойти не так и как справиться с возможными проблемами?
Какой риск считают допустимым стейкхолдеры?
y Ресурс:
Что необходимо для завершения поставки решения?
Кто будет работать над реализацией решения?
y Комплаенс:
Какие требования местного законодательства могут повлиять на решение?
Какие требования действуют в области аудита и сертификации?
Архитектор решений должен соблюдать баланс ограничений и анализировать
возможные компромиссы по каждому из них; например, экономия затрат за счет
сокращения ресурсов может повлиять на срок поставки.
Соблюдение сроков при ограниченных ресурсах может повлиять на качество,
что, в свою очередь, приведет к увеличению затрат из-за непредвиденных исправлений ошибок. Таким образом, важно найти баланс между затратами, качеством, временем и масштабом. Расползание масштаба (scope creep) — одна из
самых сложных ситуаций, с которой может столкнуться архитектор решений,
потому что это может отрицательно сказаться на всех остальных ограничениях
и повысить риски для поставки решения.
Расползанием масштаба называется постепенное расширение целей
и результатов проекта, часто без соответствующего увеличения ресурсов,
времени или бюджета.
Очень важно, чтобы архитектор решений понимал особенности всех ограничений
и имел возможность выявлять любые возникающие при этом риски. Он должен
принять планы преодоления рисков и выдержать баланс между ними. Возможность справиться с расползанием масштаба заметно помогает со своевременной
поставкой проекта.
Выбор технологии
Выбор технологии — ключевая задача архитектора решений, с которой может
быть связана наибольшая сложность. Диапазон доступных технологий огромен,
и архитектор решений должен найти подходящие технологии для решения.
Обязанности архитектора решений
57
Архитектор решений должен иметь обширные и глубокие познания в области
технологий, чтобы принять наилучшее решение, так как выбранный им технологический стек может повлиять на итоговую поставку продукта.
Любая задача имеет много решений в широком диапазоне технологий. Чтобы
сделать правильный выбор, архитектор решений должен учитывать ФТ и НФТ,
а также определить критерии выбора технологии. Выбранная технология должна
учитывать другие перспективы независимо от цели, будь то возможность интеграции с другими фреймворками и API или соблюдение требований к производительности и потребностей в области безопасности.
Архитектор решений должен быть способен выбрать технологию, которая не
только удовлетворяет текущие требования, но и масштабируется для будущих
требований.
Проверка концепции и прототип
Создание прототипа, пожалуй, самая интересная часть работы архитектора
решений. Чтобы подобрать надежную технологию, архитектор решений должен провести проверку концепции (POC) в разных технологических стеках
и проанализировать пригодность стеков для ФТ и НФТ решения. При построе
нии POC архитектор решений стремится определить структурные элементы
решения.
Идея разработки POC заключается в оценке технологии на наборе критических
функциональных реализаций, что облегчит выбор технологического стека на
основании его возможностей. POC имеет короткий жизненный цикл, а ее применение ограничивается оценкой экспертов в команде или организации.
После оценки нескольких платформ с использованием POC архитектор решений
может переходить к построению прототипа для технологического стека. Прототип разрабатывается в демонстрационных целях и передается заказчику для
обоснования финансирования. POC и прототипы далеки от уровня итогового
продукта; сборки от архитектора решений имеют ограниченную функциональность, что может усложнить разработку решения.
Проектирование и поставка решения
Архитектор приступает к решению после того, как поймет особенности ФТ, НФТ
и существующие ограничения, а также после выбора технологии. В 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 «Паттерны
проектирования архитектур решений».
Типичные сложности в работе архитектора
решений
Роль архитектора решений интересна и динамична, но и она не обходится без
сложностей. Понимание таких сложностей и умение их преодолевать абсолютно
необходимы для успеха в этой роли.
Перечислим некоторые из них.
y
y Баланс между бизнес-требованиями и техническими требованиями: архи-
y
y
тектор решений должен выдерживать баланс между удовлетворением целей
бизнеса и технической жизнеспособностью решения. Для этого необходимо
понимать как потребности бизнеса, так и технические возможности и находить оптимальное решение.
y Управление сложностью: архитектор решений часто работает со сложными
системами и технологиями, которые может быть непросто понять и интегрировать. Ему приходится ориентироваться в сложных технических средах,
применять разные компоненты и обеспечивать бесшовное взаимодействие
между ними.
y Хорошее знание технологических достижений: технологии постоянно
развиваются, регулярно появляются новые инструменты, фреймворки
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Типичные сложности в работе архитектора решений
61
и методологии. Архитектор решений должен быть в курсе новейших достижений и отраслевых тенденций, чтобы предоставлять инновационные
и эффективные решения.
Работа со стейкхолдерами: архитектор решений работает с различными
стейкхолдерами, включая руководителей бизнеса, разработчиков, руководителей проекта и конечных пользователей. Управлять разными ожиданиями,
требованиями и приоритетами бывает непросто. Навыки эффективной коммуникации, совместной работы и ведения переговоров крайне важны для
удовлетворения разнообразных потребностей стейкхолдеров.
Решение проблем масштабируемости и производительности: архитектор решений должен проектировать решения, способные справляться с возрастаю
щими объемами данных, пользовательскими нагрузками и изменяющимися
требованиями бизнеса. Обеспечение масштабируемости, производительности
и надежности очень важно, так как решения должны адаптироваться к будущему росту без потери эффективности.
Безопасность и комплаенс: безопасность данных и соблюдение регулирующих норм играют очень важную роль в современных цифровых средах.
Архитектор решений должен внедрять в свои решения надежные средства
безопасности, методы шифрования и специализированные фреймворки
для защиты конфиденциальных данных и соблюдения отраслевых стандартов.
Разрешение конфликтующих требований: у различных стейкхолдеров часто
возникают конфликты требований или приоритетов. Архитектор решений
должен разбираться в этих конфликтах, анализировать плюсы и минусы
разных вариантов и выбирать компромисс, удовлетворяющий общим целям
решения.
Управление ограничениями проекта: архитектор решений должен уметь
работать в условиях ограниченных бюджетов, сроков и ресурсов. Он должен
принимать обоснованные решения, оптимизировать распределение ресурсов
и адаптироваться к изменяющейся динамике проекта, чтобы обеспечить
успешную поставку решения.
Миграция на облачные технологии: с ростом популярности облачных вычислений архитектор решений часто сталкивается с проблемой эффективного
использования облачных платформ и сервисов. Он должен понимать нюансы
облачной архитектуры, моделей развертывания и инструментов, специфических для компании-разработчика, чтобы проектировать масштабируемые
и экономичные решения на базе облачных технологий.
Непрерывное обучение и повышение квалификации: вследствие стремительного развития технологий архитектор решений должен выделять время для
непрерывного обучения и повышения квалификации. Ему следует приобретать
новые знания, совершенствовать свою техническую квалификацию и быть
в курсе лучших практик отрасли, чтобы не утратить эффективность в работе.
62
Глава 1. Архитекторы решений в организациях
Если архитектор решений будет знать об этих проблемах и заранее принимать меры для их решения, он сможет избежать сложностей и поставлять
успешные решения, соответствующие как бизнес-целям, так и техническим
требованиям.
Карьерный путь и развитие навыков
архитектора решений
Карьерный путь архитектора решений зависит от организации, отрасли и индивидуальных устремлений. В этом разделе рассматривается общее направление
карьерного пути и развития навыков для архитекторов решений.
Карьерный путь
y
y
y
Карьерный путь архитектора решений обычно подразумевает постепенный рост
до все более значимых позиций.
y Образование: чтобы начать карьеру архитектора решений, обычно требуется иметь диплом бакалавра в области computer science, программной
инженерии или другой смежной области. При этом очень важна хорошая
подготовка в области разработки ПО, проектировании систем и знание
концепций ИТ.
y Профессиональный опыт: архитекторы решений обычно начинают свою
карьеру в качестве разработчиков, аналитиков систем или технических
консультантов. Накопление практического опыта проектирования и реализации программных решений помогает сформировать отличное понимание
практической разработки приложений и ИТ-инфраструктуры.
y Проектирование решений и архитектура: по мере карьерного роста профессионалы переходят к ролям, связанным с проектированием решений
и архитектурой. Они тесно взаимодействуют со стейкхолдерами, анализируют
бизнес-требования и проектируют масштабируемые, надежные и экономически эффективные решения. Им также пригодится опыт использования
методологий и схем архитектуры решений — таких, как TOGAF (The Open
Group Architecture Framework) или Zachman Framework.
Развитие навыков
y
Чтобы повысить свои карьерные перспективы, архитекторам решений следует
приложить усилия для развития навыков в следующих областях.
y Технические знания: архитектору решений необходим широкий спектр
технических навыков в разных областях — разработке приложений, управлении базами данных, сетях, облачных вычислениях, безопасности и т. д. Он
должен непрерывно расширять свои технические знания, чтобы быть в курсе
новейших технологий и тенденций в отрасли.
Карьерный путь и развитие навыков архитектора решений
63
y
y Коммуникация и совместная работа: эффективные навыки коммуникации
y
y
y
и совместной работы исключительно важны для архитекторов решений.
Архитектор должен быть способен объяснять технические концепции
в терминах, понятных нетехническим стейкхолдерам, быть фасилитатором
в дискуссиях и формировать консенсус. Развитие сильных навыков коммуникации и лидерства чрезвычайно важно для эффективной работы с кроссфункциональными командами.
y Деловые качества: архитектор решений должен координировать технологические решения с бизнес-целями. Развитие деловых качеств помогает
ему лучше понять стратегии организации, динамику отрасли и потребности
заказчика. Архитектор должен быть способен проанализировать влияние
технологических решений на бизнес в целом и дать соответствующие рекомендации.
y Лидерство и управление: по мере развития карьеры архитектор решений
может выступать руководителем и менеджером, отслеживая работу команд
архитекторов или управляя проектами поставки решений. Развитие навыков
управления проектами, руководства командами и стратегического планирования способствует умению добиваться успешного результата.
y Непрерывное обучение: сфера технологии постоянно развивается, и архитекторы решений должны проактивно стремиться к знаниям. Очень важно
постоянно оставаться в курсе появляющихся технологий, лучших отраслевых
практик и новых архитектурных паттернов. Прохождение сертификаций
и участие в отраслевых конференциях и семинарах способствует непрерывному профессиональному развитию.
В современной цифровой среде облачные вычисления стали неотъемлемой
частью архитектур решений. Облачные платформы обеспечивают масштабирование, гибкость и экономическую эффективность, делая возможными быстрое
развертывание и масштабирование приложений. Они также открывают доступ
к таким современным технологиям, как искусственный интеллект, анализ
больших данных и IoT, играющим ключевую роль в стратегиях цифровой
трансформации. Таким образом, хорошее знание облачных решений поможет
архитектору проектировать эффективные, конкурентоспособные решения,
которые останутся актуальными в будущем.
y
y
Перечислим ключевые знания и сертификаты в сфере облачных технологий,
которыми должен обладать архитектор решений.
y Облачные платформы: облачный архитектор должен быть знаком с основными облачными платформами — такими, как Amazon Web Services (AWS),
Microsoft Azure и Google Cloud Platform (GCP). Он должен знать основные
сервисы, архитектурные паттерны, варианты масштабирования и средства
безопасности, предоставляемые этими платформами.
y Облачная архитектура: архитекторы решений должны хорошо разбираться
в проектировании архитектур на базе облака. В частности, это подразумевает
64
Глава 1. Архитекторы решений в организациях
y
y
y
проектирование решений с высокой доступностью и масштабируемостью,
реализацию отказоустойчивых систем, а также оптимизацию затрат и производительности в облачных средах.
y Облачная безопасность: безопасность — одно из важных условий облачных
вычислений. Архитектор решений должен знать лучшие практики облачной
безопасности, механизмы шифрования, управление идентификацией и доступом, а также стандарты соответствия, специфические для облачных сред.
Кроме того, важно понимать, как проектируются и реализуются безопасные
облачные архитектуры.
y Облачные хранилища и базы данных: архитектор решений должен хорошо понимать варианты хранения данных в облаке — хранилища объектов,
блоков и файлов — и уметь выбирать подходящее решение в зависимости
от конкретных требований. Кроме того, архитектору пригодятся знания облачных сервисов баз данных — таких, как Amazon RDS, Azure SQL Database
и Google Cloud Spanner.
y Облачные сертификаты: облачные сертификаты проверяют знания
специалиста по облачным технологиям; их наличие способствует более
высокому уровню доверия к специалисту. К числу популярных облачных сертификатов для архитекторов решений относятся 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
В главе представлены различные роли архитектора решений — как широкого
профиля, так и специализированные. Для каждой роли было приведено краткое
описание, раскрывающее специфические обязанности и знания.
Затем были подробно рассмотрены важнейшие обязанности архитектора решений: анализ требований пользователей, определение НФТ, общение со стейкхолдерами, управление архитектурными ограничениями, выбор подходящих
технологий, разработка POC, проектирование и поставка решений, обеспечение
работоспособности и обслуживания после запуска, а также евангелизм технологий.
В этой главе также уделено внимание интеграции архитекторов решений в команды Agile. При этом подчеркивалась важность совместной работы, адаптируемости
и непрерывного улучшения в рамках процесса Agile-разработки.
Перечислены типичные проблемы, с которыми сталкиваются архитекторы решений, и даны рекомендации по их эффективному решению. Мы подчеркнули
необходимость непрерывного профессионального развития и совершенствования навыков, чтобы не отстать от развивающихся технологий и отраслевых
тенденций.
Эта глава, в которой подробно рассматриваются основные характеристики роли
архитектора решений, станет руководством как для начинающих, так и для
практикующих профессионалов. Представленный обзор закладывает основу
для всестороннего исследования архитектуры решений.
В следующих главах мы обсудим принципы проектирования масштабируемых,
устойчивых и высокопроизводительных архитектур. Они касаются таких важных
вопросов, как применение мер безопасности, планирование в условиях архитектурных ограничений и реализация изменений посредством тестирования
и автоматизации.
ГЛАВА 2
ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ
АРХИТЕКТУР РЕШЕНИЙ
В этой главе мы рассмотрим самые важные и распространенные принципы
проектирования и свойства архитектуры решений. Хотя здесь наше внимание
будет сосредоточено на ключевых элементах проектирования, стоит заметить,
что в зависимости от сложности продукта и конкретной предметной области
могут возникать дополнительные особенности. По мере чтения книги вы более
глубоко изучите фундаментальные принципы и свойства, в том числе те, что
применяются в разработке различных паттернов, предназначенных для разных
сценариев и ситуаций.
Мы поговорим в этой главе о принципах проектирования масштабируемых
и устойчивых архитектур, отличающихся оптимизированной производительностью, но при этом использующих надежные меры безопасности для защиты
приложения. Мы исследуем стратегии планирования в условиях архитектурных ограничений, а также стратегии внедрения изменений через тестирование
и автоматизацию, уделяя особое внимание подходу к проектированию на основе
данных. Если вы будете понимать и применять эти принципы, у вас будет все
необходимое, чтобы мыслить критически и принимать обоснованные решения,
повышающие эффективность и надежность дизайна архитектуры.
y
y
y
y
y
y
y
y
y
y
y
В этой главе рассматриваются следующие темы.
y Построение масштабируемой архитектуры.
y Построение архитектуры, обладающей высокой доступностью и отказоустойчивостью.
y Проектирование с учетом производительности.
y Создание неизменяемых архитектур.
y Слабая связанность.
y Сервисы, а не серверы.
y Проектирование на основе данных.
y Забота о безопасности на всех уровнях.
y Создание удобных и доступных приложений.
y Построение future-proof расширяемых архитектур.
y Архитектурная интероперабельность и портируемость.
Построение масштабируемых архитектур
67
y
y
y
y Повсеместное внедрение автоматизации.
y Планирование непрерывности бизнеса.
y Преодоление архитектурных ограничений.
Начнем с исследования фундаментальных элементов проектирования архитектуры. К концу этой главы вы получите достаточно знаний о ключевых особенностях проектирования, которые следует учитывать при разработке архитектуры.
Эти знания станут важной вехой на вашем пути к пониманию и реализации
эффективных и надежных архитектурных решений.
Построение масштабируемых архитектур
Масштабируемость всегда была одним из важнейших факторов проектирования.
Если вы попросите любую организацию описать внедренные в ней решения,
одним из главных свойств этих решений, скорее всего, будет названа масштабируемость. Масштабируемостью называется способность системы справляться
с растущими рабочими нагрузками, которые могут применяться к нескольким
уровням — серверам приложений, веб-приложениям и базам данных. Масштабируемость помогает выполнять запросы пользователей без последствий для
производительности приложения, что приводит к повышению прибыли для
бизнеса.
Так как большинство приложений в наши дни строится на базе веб-технологий,
также стоит поговорить об эластичности (elasticity). Этим термином обозначаются способность системы к росту за счет добавления новой функциональности
и ее сокращение в целях избегания лишних затрат. С принятием публичных облачных платформ появилась возможность быстро повышать и понижать рабочую
нагрузку, а эластичность пришла на смену масштабируемости.
y
y
Традиционно существовали два режима масштабирования.
y Горизонтальное масштабирование: его популярность выросла за последнее
десятилетие, когда вычислительные ресурсы стремительно дешевели. При
горизонтальном масштабировании подключают больше серверов для обработки повышающейся нагрузки, как показано на рис. 2.1.
Представим, что ваше приложение способно обработать 1000 запросов в секунду
двумя экземплярами на серверах. С ростом пользовательской базы приложение
начинает получать 2000 запросов в секунду, и это означает, что придется удвоить количество экземпляров приложения (доведя его до четырех), чтобы оно
справлялось с повышенной нагрузкой.
y Вертикальное масштабирование: применяется уже давно. При этой практике для обработки повышенных рабочих нагрузок на имеющиеся серверы
добавляют дополнительное пространство хранения данных и памяти. Как
показано на рис. 2.2, при вертикальном масштабировании вы получаете
более мощные серверы (вместо добавления новых серверов) для обработки
повышенной нагрузки.
68
Глава 2. Принципы проектирования архитектур решений
Рис. 2.1. Горизонтальное масштабирование
Рис. 2.2. Вертикальное масштабирование
Модель вертикального масштабирования может быть менее экономичной; затраты на оборудование с дополнительной вычислительной мощностью и памятью
растут экспоненциально. По достижении определенного порога от вертикального
масштабирования стоит отказаться, если только оно не стало единственным возможным вариантом из-за высоких затрат и ограничений на количество серверов.
Вертикальное масштабирование — более распространенный способ масштабирования серверов реляционных баз данных. Впрочем, при достижении сервером
Построение масштабируемых архитектур
69
порога вертикального масштабирования стоит подумать о шардировании
(sharding) базы данных, так как она не сможет преодолеть ограничения памяти
и вычислительной мощности.
Шардирование — метод масштабирования БД, основанный на разделении
и распределении данных между несколькими серверами. Данные разбиваются
по значению ключа шарда, который определяет, каким образом они будут
распределены между шардами. При вертикальном шардировании ключом
сегмента может быть конкретный столбец или группа столбцов в таблице.
Масштабирование может быть упреждающим, если у вас есть информация
о рабочей нагрузке, как это обычно бывает, или же реактивным, если возникнет
неожиданный пик или вам еще не приходилось иметь дела с такой нагрузкой.
Упреждающее масштабирование (predictive scaling) — продвинутый способ
управления рабочими нагрузками приложений, особенно в сценариях с предсказуемым трафиком (как, например, на сайтах интернет-магазинов). Анализируя исторические данные, организации могут прогнозировать закономерности
трафика и соответственно регулировать свои ресурсы .
Трафик на сайте интернет-магазина может различаться в зависимости от дня
недели, времени суток или праздников, что обусловливает применение стратегии
масштабирования, принудительно корректирующей ресурсы для обработки ожидаемой нагрузки. Такой подход не только оптимизирует использование ресурсов,
но и улучшает взаимодействие с пользователями за счет сокращения задержки
и предотвращения простоев. Это особенно важно при выбросах трафика, когда
распределение ресурсов может отставать от спроса.
Другой вид маcштабирования — реактивное (reactive) — играет важную роль
для преодоления непредвиденных всплесков трафика, которые могут заметно
превышать норму и инициироваться такими событиями, как краткосрочные
распродажи. Понимание специфических паттернов трафика для разных страниц веб-сайта, а также навигации пользователя очень важно для эффективного
управления выбросами. Определяя, какие страницы могут кэшироваться или
какие запросы требуют интенсивного чтения, организации могут стратегически
выводить трафик с веб-уровня, используя сети распространения контента (CDN)
для управления статическим контентом.
Такое сочетание упреждающего и реактивного масштабирования обеспечивает
устойчивость и быстрый отклик приложения независимо от колебаний трафика.
Например, у показанной на рис. 2.3 группы Auto Scaling максимальный размер
составляет шесть экземпляров, а минимальный — три экземпляра. При обычном пользовательском трафике рабочая нагрузка будет обслуживаться тремя
работающими серверами, но количество серверов может достигать шести при
пиках трафика. Парк серверов должен расширяться в соответствии с политиками
масштабирования, определенными для корректировки количества экземпляров.
70
Глава 2. Принципы проектирования архитектур решений
Группа Auto Scaling
Минимальное количество серверов
Серверы, доступные для масштабирования по необходимости
Максимальное количество серверов
Рис. 2.3. Автоматическое масштабирование серверов
Например, политика может добавлять один сервер, когда загрузка процессора
превышает 60 % в парке существующих серверов, но их общее количество не
может превысить шесть.
Независимо от того, будет ли масштабирование упреждающим или реактивным,
необходимо отслеживать состояние приложения и собирать данные для планирования потребностей в масштабировании.
Масштабирование статического контента
Статический контент (графика, видео и т. д.) играет важнейшую роль в привлечении пользователей на веб-сайты. Тем не менее при неправильном управлении эти
элементы могут значительно замедлить работу приложения. Чтобы обеспечить
оптимальную скорость и взаимодействие с пользователем, важно организовать
эффективное масштабирование и распределение статического контента.
Для примера возьмем сайт интернет-магазина. Скорее всего, для каждого товара будут добавлены несколько изображений (а может, даже видеороликов),
представляющих внешний вид товара и его использование. Это означает, что
сайт будет содержать значительный объем статического контента, создающего
нагрузку с интенсивным чтением, потому что большую часть времени пользователи будут просматривать товары. Кроме того, пользователи могут отправлять
графику и видеоролики в обзорах или отзывах на товары.
Хранение статического контента на веб-сервере означает затраты большого
объема памяти хранилища, и с расширением списка товаров придется беспокоиться о масштабировании хранилища. Другая проблема заключается в том, что
статический контент хранится в файлах большого размера, что может создать
значительную задержку с загрузкой на стороне пользователя. Для решения этой
проблемы уровень веб-архитектуры должен использовать сеть распространения
контента, или CDN (Content Distribution Network). Сети CDN помогают кэшировать контент ближе к пользователю, сокращая задержку и ускоряя загрузку.
Построение масштабируемых архитектур
71
Правильное масштабирование статического контента обеспечивает быстроту
и отзывчивость приложения, а это означает беспроблемное взаимодействие
с пользователем даже в условиях роста объема трафика.
Поставщики CDN (такие, как Akamai, Amazon CloudFront, Microsoft Azure
CDN и Google CDN) создают по всему миру сеть центров, в которых статический контент может кэшироваться на веб-сервере, находящемся поблизости
от пользователя, что приводит к сокращению задержки. В главе 4 «Паттерны
проектирования архитектур решений» вы больше узнаете о кэшировании.
Для кэширования статического контента рекомендуется использовать хранилище объектов — такое, как Amazon S3, или специальное локальное хранилище,
которое может расти независимо от объема памяти и мощности компьютеров.
Кроме того, независимое масштабирование пространства хранения с помощью
популярных сервисов хранения объектов снижает затраты. Такие решения
могут хранить статические страницы HTML, чтобы снизить нагрузку на
веб-серверы и улучшить взаимодействие с пользователем за счет сокращения
задержки.
Управление сессиями для масштабирования
серверов приложений
Архитектурный уровень приложения получает пользовательские запросы с вебуровня и выполняет большую работу по вычислению бизнес-логики и взаи
модействию с базой данных. При возрастании количества пользовательских
запросов уровень приложения должен масштабироваться, чтобы обработать
их без задержек, а затем снова сократиться при снижении нагрузки. В таких
сценариях пользователи привязываются к сессии, в которой они, например,
могут просматривать информацию с мобильного устройства и покупать товары
с десктопного компьютера. Выполнение горизонтального масштабирования
без поддержки сессий пользователей может ухудшить взаимодействие с пользователем, так как предыдущие действия пользователя в процессе покупки
сохраняться не будут.
Прежде всего следует отделить пользовательские сессии от экземпляра сервера
приложения. Это означает, что сессии должны поддерживаться на независимом
уровне — скажем, в базе данных NoSQL, в которой будут храниться частично
структурированные данные.
Базы данных NoSQL лучше всего подходят для частично структурированных
данных с изменяющейся схемой. Например, один пользователь может
ввести свое имя и адрес при создании пользовательского профиля. Другой
пользователь может ввести дополнительные атрибуты: номер телефона, пол,
семейное положение, имя и адрес. Хотя набор атрибутов пользователей
будет отличаться, базы данных NoSQL справятся с хранением информации
и обеспечат быстрый поиск.
72
Глава 2. Принципы проектирования архитектур решений
Базы данных NoSQL — такие, как Amazon DynamoDB или MongoDB — предоставляют исключительные возможности секционирования, обеспечивая легкое
горизонтальное масштабирование более высокого уровня, чем другие виды баз
данных.
Когда вы начнете хранить пользовательские сессии в базах данных NoSQL,
ваш экземпляр сможет масштабироваться горизонтально без ущерба для взаи
модействия с пользователем. Вы можете добавить балансировщик нагрузки
перед парком серверов приложений, и он будет распределять нагрузку между
экземплярами. С помощью автомасштабирования можно автоматизировать
добавление или удаление экземпляров по требованию.
Масштабирование баз данных
Многие приложения используют реляционные БД для хранения данных транз
акций. Технология реляционных БД существует уже несколько десятилетий
и обеспечивает надежную целостность транзакций, необходимую для многих
приложений. Тем не менее главный недостаток таких баз заключается в том, что
они не могут масштабироваться по горизонтали, если не предусмотреть другие
методы (например, шардирование) и не внести соответствующие изменения
в приложение. Это потребует значительных усилий.
Более разумным подходом будет превентивно сократить нагрузку на базы
данных. Сочетание разных методов хранения — таких, как хранение пользовательских сессий в отдельных базах данных NoSQL, хранение статического
контента в хранилище объектов и использование внешнего кэша — позволяет
снизить нагрузку на основную базу данных. Лучше зарезервировать узел главной
базы данных для записи и обновления данных и использовать дополнительную
реплику для всех запросов на чтение. Например, Amazon RDS для MySQL
предоставляет для реляционных баз данных до 15 реплик для чтения.
Реплики для чтения могут создавать миллисекундные задержки при синхронизации с ведущим узлом, и следует учесть этот факт при проектировании
приложения. Также рекомендуется использовать механизм кэширования (например, Memcached или Redis) для сохранения частых запросов и, как следствие,
сокращения нагрузки на ведущий узел.
Если емкость базы данных начнет выходить за текущие границы, придется перепроектировать БД и разделить на шарды, применяя методы секционирования.
Каждый шард может расти независимо, а приложение должно определить
ключ для сохранения пользовательских данных в соответствующем шарде.
Например, если ключом раздела является имя пользователя (user_name), то
пользователи с именами от A до E могут храниться в одном шарде, пользователи
с именами от F до I — в другом и т. д. Приложение должно направлять записи
пользователей в соответствующий раздел в зависимости от первой буквы имени.
Как видите, масштабируемость является важным фактором при проектировании
архитектуры приложения и при неправильном планировании может оказать
Построение масштабируемых архитектур
73
значительное влияние на общий бюджет проекта и взаимодействие с пользователем. Архитектор решений всегда должен учитывать фактор эластичности при
проектировании приложений и оптимизации рабочих нагрузок, чтобы достичь
оптимальной производительности и минимизировать затраты.
Архитектор решений должен оценить разные варианты (например, CDN) для
масштабирования статического контента и распределения нагрузки, варианты
автомасштабирования для масштабирования серверов и различные варианты
хранения данных для кэширования, хранилищ объектов, хранилищ NoSQL,
реплик для чтения и шардирования.
Построение эластичной архитектуры
При обеспечении масштабируемости для улучшения производительности
приложения важно сохранять экономическую эффективность архитектурных
решений. Отсюда следует, что при расширении инфраструктуры сервера для
удовлетворения растущей пользовательской нагрузки система также должна
сокращаться при снижении нагрузки. Эластичность необходима для подбора
оптимального размера архитектуры, что подразумевает масштабирование инфраструктуры сервера в соответствии с текущей нагрузкой. По сути, необходимо обеспечить достаточную емкость для эффективной обработки аномальных
нагрузок без выделения избыточных ресурсов, которые будут простаивать при
отсутствии пиков.
Продолжим наш пример с сайтом интернет-магазина. Возьмем современную
трехуровневую архитектуру и посмотрим, как достичь эластичности на другом
уровне приложения. Мы будем обращать внимание только на вопросы эластичности и масштабируемости. На рис. 2.4 представлена трехуровневая архитектурная диаграмма облачного технологического стека AWS.
На диаграмме изображена трехуровневая архитектура, обладающая эластичностью и высокой доступностью, с упором на построение эластичного парка
серверов для эффективного управления переменными нагрузками.
y
y
Основные компоненты этой архитектуры:
y Эластичный балансировщик нагрузки автоматически распределяет входящий
трафик приложения по нескольким целям — например, экземплярам Amazon
Elastic Compute Cloud (EC2), контейнерам, IP-адресам и т. д. — в нескольких
зонах доступности. Таким образом повышается отказоустойчивость приложения интернет-магазина.
y Веб-уровень состоит из группы Auto Scaling экземпляров EC2, спроектированных для обслуживания динамического контента приложения. Этот
парк серверов может автоматически добавлять или удалять экземпляры на
основании определенных критериев (например, загрузки процессора); это
гарантирует, что парк сможет адаптироваться к входящему трафику и поддерживать стабильную производительность.
74
Глава 2. Принципы проектирования архитектур решений
y
y Уровень приложения также содержит группу Auto Scaling экземпляров EC2,
y
отвечающих за выполнение бизнес-логики приложений. Как и веб-уровень,
он может динамически регулировать свой размер под потребности рабочей
нагрузки приложения.
y Уровень базы данных содержит экземпляры Amazon RDS (Relational Database
System), представляющие собой управляемые реляционные базы данных.
Конфигурация включает первичный экземпляр БД и реплику для чтения,
которая используется для операций с интенсивным чтением, улучшая производительность и сокращая нагрузку на первичный экземпляр. Также существует резервный экземпляр в другой зоне доступности, он обеспечивает
высокую доступность и поддержку восстановления при сбоях.
Эта архитектура формирует гибкую, масштабируемую среду приложения,
которая способна справиться с переменными рабочими нагрузками и обладает высокой доступностью в нескольких зонах. Она способна автоматически
расширяться и сокращаться в соответствии с потребностями приложения,
обеспечивая стабильную и отзывчивую производительность взаимодействий
с пользователями.
Когда пользователи обращаются к приложению и взаимодействуют с ним, используя веб-сайт или мобильное приложение, их запросы маршрутизируются
через Amazon Route 53 — веб-сервис DNS (Domain Name System), обладающий
высокой доступностью и масштабированием. Amazon CloudFront (CDN) используется для эффективного распространения статического контента: графики,
таблиц стилей и файлов JavaScript. Таким образом сокращается нагрузка на
веб-серверы, а взаимодействие с пользователем улучшается за счет снижения
задержки.
Облако AWS
Amazon S3
Route 53
Зона доступности 1
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Amazon RDS
Реплика экземпляра
БД, предназначенная
для чтения
Балансировщик нагрузки Elastic Load Balancer
Зона доступности 2
Уровень приложения
Веб-уровень
Кластер серверов Amazon EC2
Уровень приложения
Веб-уровень
Кластер серверов Amazon EC2
Уровень базы данных
Реплика экземпляра БД,
предназначенная
для чтения
Резервный экземпляр
базы данных
Рис. 2.4. Масштабирование трехуровневой архитектуры
Amazon
CloudFront
Пользователи
Построение устойчивой архитектуры с высокой доступностью
75
В этом разделе были представлены различные методы масштабирования и возможности внедрения эластичности на разных уровнях архитектуры. Масштабируемость является важным условием, которое обеспечивает высокую доступность
приложения и делает его устойчивым. Высокая доступность и устойчивость
более подробно рассматриваются в следующем разделе.
Построение устойчивой архитектуры
с высокой доступностью
Создание устойчивой архитектуры с высокой доступностью подразумевает проектирование систем, которые могут обработать отказы отдельных компонентов
без нарушения функциональности системы в целом.
Архитектура с высокой доступностью
Любая организация стремится избежать простоев. Простои приложения приводят к утрате доверия со стороны бизнеса и пользователей, поэтому высокая
доступность (high availability, HA) становится одним из важнейших факторов
при проектировании архитектуры решения. Главный принцип высокой доступности звучит так: «Проектируй с учетом отказов, и отказов не будет».
Требования ко времени безотказной работы зависят от конкретного приложения.
Если приложение предназначено для большой базы внешних пользователей (например, сайт интернет-магазина или социальная сеть), необходимо обеспечить
100%-ную работоспособность. В случае внутреннего приложения (к которому
обращаются работники компании — например, система учета персонала или
интрасеть компании) могут быть приемлемы непродолжительные простои. Высокая доступность напрямую связана с затратами, поэтому архитектор решений
всегда должен планировать ее с учетом других требований.
При создании архитектуры с высокой доступностью лучше выделить для рабочих нагрузок изолированный физический участок, чтобы при возникновении
сбоя в одном месте реплика приложения могла бы работать из другого места.
Архитектура с высокой доступностью непосредственно связана с самовосстановлением, когда вы стремитесь обеспечить стабильную работу приложения, но
тем не менее необходим механизм быстрого восстановления после сбоя, чтобы
поддержать желаемое качество пользовательского опыта.
Устойчивая архитектура
Устойчивая (resilient) архитектура означает, что приложение должно оставаться доступным для пользователей во время восстановления после сбоя.
Устойчивость включает применение лучших практик для восстановления приложения после повышенных нагрузок, обусловленных увеличением количества
76
Глава 2. Принципы проектирования архитектур решений
пользовательских запросов, злонамеренных атак и отказов компонентов архитектуры. Она должна существовать на всех уровнях архитектуры, включая уровни
инфраструктуры, приложения, баз данных, безопасности и сетей. Устойчивая
архитектура должна восстанавливаться после сбоев за желаемое время.
y
y
Чтобы сделать архитектуру устойчивой, необходимо определить время восстановления и решить следующие задачи:
y определить и реализовать избыточные архитектурные компоненты там, где
это требуется;
y понять, когда следует исправлять архитектурные компоненты, а когда их
лучше заменять. Например, исправление проблемы с сервером может занять
больше времени, чем его замена образом той же машины.
Достижение избыточности
Избыточность — критически важное условие построения устойчивых систем.
Создание устойчивой архитектуры требует многоуровневой стратегии избыточности. Эта стратегия включает развертывание серверных кластеров на разных
стойках в одном дата-центре, расширение на несколько дата-центров в одном
регионе и далее по разным географическим регионам. Географическое распределение обеспечивает защиту от локальных и региональных стихийных бедствий
и сокращает задержку для глобальной пользовательской базы.
Внедрение интеллектуального распределения нагрузки и глобального управления трафиком (например, маршрутизации на базе DNS с проверкой работоспособности) гарантирует, что пользователи всегда будут обслуживаться из наиболее
подходящей локации. Устойчивость баз данных достигается стратегической
репликацией, с автоматизированными механизмами отработки отказов для
поддержания доступности и целостности баз данных.
Если серверы распределены по разным физическим локациям, первый уровень
маршрутизации трафика может обеспечиваться сервером DNS еще до того, как
трафик достигнет балансировщика нагрузки. Таким образом в случае сбоя во
всем регионе приложение будет работать.
y
Как видно из приведенного выше рисунка, устойчивость должна обеспечиваться на всех критических уровнях, влияющих на доступность архитектуры; это позволит реализовать решение, способное пережить сбои. Помимо
использования сервера DNS для маршрутизации трафика между разными
физическими локациями, необходимо применять следующие лучшие практики,
чтобы сформировать избыточную среду и обеспечить устойчивость:
y использовать CDN для распределения и кэширования статического контента
(видео, графики, статических веб-страниц) поблизости от местонахождения
пользователя, чтобы приложение всегда оставалось доступным;
Пользователь
Веб-сайт
Регион A
Балансировщик нагрузки
Автомасштабирование
Парк
серверов
Главная
база данных
Сервер
DNS
Построение устойчивой архитектуры с высокой доступностью
77
CDN
Регион B
Балансировщик нагрузки
Автомасштабирование
Парк
серверов
Резервная
база данных
Рис. 2.5. Обеспечение устойчивости архитектуры приложений
с использованием сервера DNS
y
y по достижении трафиком границ региона применять балансировщик нагрузки
y
y
для маршрутизации трафика по парку серверов, чтобы приложение работало
даже в том случае, если один узел в регионе потеряет работоспособность;
y использовать автомасштабирование для добавления или удаления серверов
в зависимости от потребности пользователя. Так приложение не будет зависеть от сбоев отдельных серверов;
y создавать резервную базу данных, чтобы приложение оставалось доступным
в случае сбоя основной БД.
Обработка отказов компонентов
На случай отказа какого-либо компонента должна существовать его резервная
копия для восстановления и достижения устойчивости архитектуры. Балансировщик нагрузки и маршрутизаторы на сервере DNS выполняют проверку
работоспособности, чтобы убедиться, что трафик направляется только к работоспособным экземплярам приложения. Эту схему можно настроить для поверхностной проверки работоспособности, при которой отслеживаются локальные
сбои хостов, или глубокой проверки, при которой также могут решаться проблемы со сбоями зависимостей. Однако глубокая проверка работоспособности
78
Глава 2. Принципы проектирования архитектур решений
занимает больше времени и требует бˆольших ресурсов, чем поверхностная. Вы
узнаете больше об устойчивых архитектурах в главе 8 «Факторы надежности
архитектуры».
y
y
y
y
На уровне приложений важно избегать каскадных отказов, при которых отказ
одного компонента может вывести из строя всю систему. Для снижения риска
каскадных отказов в системе могут применяться различные механизмы.
y Тайм-ауты: назначение максимального времени для операций и запросов
может предотвратить бесконечное ожидание ответа, приводящее к истощению ресурсов.
y Отклонение трафика: перегруженная система может активно отклонять
новые запросы, чтобы предотвратить перегрузку и обеспечить стабильность
существующих процессов.
y Идемпотентные операции: обеспечение повторяемости операций без нежелательных эффектов может способствовать восстановлению после промежуточных отказов без дублирования действий или появления несогласованности состояний.
y Прерыватели: реализация паттерна «Прерыватель» (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, сети хранения данных)
могут читать и записывать данные. Каждая операция ввода или вывода может
быть операцией чтения или записи данных.
y
y
y
y
y
y
y
При добавлении кэширования на разных уровнях архитектуры приложения
необходимо учитывать следующее:
y для загрузки часто запрашиваемых веб-страниц используйте кэш браузера
в системе пользователя;
y для быстрого поиска веб-сайтов — кэш DNS;
y для графики высокого разрешения и видеороликов, хранящихся поблизости
от местоположения пользователя, — кэш CDN;
y для обслуживания частых запросов из памяти — кэш базы данных;
y на уровне серверов используйте максимальный объем кэша в памяти для
обслуживания пользовательских запросов;
y для обслуживания частых запросов из системы кэширования применяйте
такие механизмы кэширования, как Redis и Memcached;
y предусмотрите ситуацию устаревания кэша — это процесс, в результате
которого данные кэша становятся неактуальными и помечаются на обновление или удаление. Вытеснение данных из кэша — процесс, в результате
которого данные удаляются из кэша, обычно чтобы освободить место для
новых данных.
Как видите, забота о производительности приложения — важная задача проектирования, напрямую связанная с прибыльностью организации. Архитектор
решений должен думать о производительности при планировании решения и постоянно работать над ее повышением. В главе 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). На следующей
архитектурной диаграмме показано разделение связей на базе очереди. В этой
ситуации слабая связанность систем достигается благодаря использованию
очередей между системами и обмену сообщениями, которые передают задания.
Сохранение изображения
Кодирование изображения
Очередь
Генерирование
миниатюр
Очередь
Создание
водяного
знака
с копирайтом
Очередь
Рис. 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 повышает конфиденциальность данных
в Евросоюзе, а SOC обеспечивает безопасность управления данными в обслуживающих организациях, устанавливая меры безопасности для защиты
клиентских данных и предоставляя организациям рекомендации по соблюдению стандартов. В зависимости от отрасли и региона также необходимо
соблюдать местное законодательство.
Безопасность может значительно влиять на дизайн решения, так что понять потребности в безопасности необходимо еще до начала проектирования. Безопасность должна быть внедрена в платформу на аппаратном уровне и в разработку
приложения на программном уровне.
y
y
Ниже перечислены ключевые соображения, которые необходимо учесть на
этапе проектирования.
y Физическая безопасность дата-центра: все ИТ-ресурсы в дата-центрах
должны быть защищены от несанкционированного доступа.
y Сетевая безопасность: сеть должна быть защищена для предотвращения
любых попыток несанкционированного доступа к серверам.
88
Глава 2. Принципы проектирования архитектур решений
y
y Управление доступом и идентификационными данными (IAM, Identity and
y
y
y
Access Management): только пользователи, прошедшие аутентификацию,
должны иметь доступ к приложению, при этом им разрешается выполнение
операций, соответствующих их уровню авторизации.
y Безопасность данных при передаче: данные должны быть защищены при
передаче по сети или интернету.
y Безопасность данных при хранении: данные должны быть защищены при
хранении в базе данных или другом хранилище.
y Мониторинг безопасности: любые инциденты безопасности должны быть
обнаружены, а команда поставлена в известность для дальнейших действий.
При проектировании приложения необходимо соблюдать баланс требований
безопасности (например, шифрования) и других факторов (таких, как производительность и задержка). Шифрование данных всегда влияет на производительность, поскольку добавляет уровень обработки — данные необходимо
дешифровать для использования. Затраты на дополнительную обработку шифрования не должны влиять на общую производительность приложения, поэтому
при проектировании приложения следует продумать сценарии использования,
в которых требуется шифрование. Например, если приложение работает с конфиденциальными данными, их необходимо зашифровать.
Другой аспект, относящийся к безопасности, который необходимо учитывать
при проектировании приложений, — комплаенс, соответствие локальному законодательству. Это особенно важно, если приложение относится к регулируемой
отрасли: здравоохранению, финансам или федеральной власти. У каждого вида
комплаенса есть свои требования, в которые обычно входит защита данных
и регистрация всех операций для целей аудита. Дизайн приложения должен
включать систему ведения журналов и мониторинга, которая будет удовлетворять требованиям аудита.
Безопасность — одно из самых важных условий устойчивости приложений.
С точки зрения безопасности DDoS-атака (Distributed Denial of Service, то есть
«распределенный отказ в обслуживании») потенциально может повлиять на доступность сервисов и приложений. DDoS-атаки обычно генерируют фиктивный
трафик к серверу и перегружают его, в результате чего легитимные пользователи
не могут обратиться к приложению. Это может происходить на сетевом уровне
или на уровне приложения. Важно принять упреждающие меры для предотвращения DDoS-атак. Старайтесь располагать как можно более значительную
часть рабочей нагрузки приложения в частной сети и не предоставлять доступ
к конечным точкам приложения из интернета, если это возможно.
Автоматизация безопасности — еще один фактор, который необходимо последовательно реализовать при проектировании, чтобы сократить риск нарушений безопасности. Автоматизация в безопасности подразумевает применение
Удобство использования и доступность приложений
89
технологии для выполнения задач безопасности без вмешательства человека,
оптимизацию обнаружения, анализа и исправления инцидентов безопасности.
Интегрируя автоматизированные средства безопасности, можно обеспечить непрерывный мониторинг и обнаружение угроз в реальном времени, что ускорит
реагирование на попытки взлома и уязвимости.
В этом разделе вы узнали, как применять принципы безопасности при
проектировании и учитывать нормативные требования. Впрочем, это лишь
общий обзор. Более подробно тема рассматривается в главе 7 «Факторы
безопасности».
Даже продукт с широкой функциональностью может не понравиться пользователям, если с ним будет неудобно работать. Удобство использования и доступность приложения чрезвычайно важны для успеха продукта. Об этом вы больше
узнаете в следующем разделе.
Удобство использования и доступность
приложений
Важными параметрами дизайна также являются удобство использования (юзабилити) и доступность приложения, которые оказывают значительное влияние
на опыт пользователя. Юзабилити определяет, насколько просто и интуитивно
взаимодействие с приложением; в частности, это подразумевает понятный интерфейс, логичную навигацию и эффективные процессы выполнения действий.
Доступность означает, что с приложением смогут работать люди с ограниченными возможностями. Рассмотрим эти параметры более подробно.
Удобство использования
У пользователей не должно возникать проблем при работе с приложением. Она
должна проходить настолько гладко, чтобы пользователь даже не заметил, как
легко он находит нужную информацию.
Удобство использования, или юзабилити, определяет, насколько быстро пользователь может освоить логику навигации при знакомстве с приложением.
Кроме того, важно, насколько быстро пользователь возвращается к нормальной
работе после допущенной ошибки и оптимальны ли его действия. Сложные
и полнофункциональные приложения имеют смысл только в том случае,
если с ними можно эффективно работать. Ваша цель — создать интуитивный
и удобный интерфейс, который улучшает взаимодействие с пользователем
и гарантирует, что функциональность приложения будет доступной и понятной для всех.
Важную роль в проектировании с учетом удобства использования играют исследования пользователей и тестирование.
90
Глава 2. Принципы проектирования архитектур решений
Доступность
Проектируемое приложение часто предназначено для глобальной аудитории или
широкого географического региона. У пользователей будут разные технические
и физические возможности. Доступность означает инклюзивность: приложение
должно быть доступно всем, включая пользователей с медленным интернетом,
владельцев устаревших устройств или людей с ограниченными возможностями.
При проектировании приложения архитектор решения обязательно должен
учитывать фактор доступности. Иногда для этого приходится создавать отдельную версию приложения.
Решение с высокой доступностью должно включать такие компоненты, как
распознавание голоса и голосовая навигация, экранные лупы и экранные дикторы — например, для слабовидящих пользователей.
Локализация помогает сделать приложение доступным на языке конкретного
региона (например, испанском, немецком, хинди или японском), чтобы глобальные пользователи со всего мира могли взаимодействовать с приложением
на языке своего региона.
Как показано на рис. 2.11, юзабилити и доступность формируют удовлетворенность потребителей.
Пользовательский
опыт
Юзабилити
Удовлетворенность
потребителей
Доступность
Рис. 2.11. Удовлетворенность потребителей как следствие удобства
использования и доступности
Для обеспечения юзабилити и доступности необходимо знать своих пользователей, причем доступность является частью удобства использования, так как
они неразрывно связаны. Прежде чем приступать к проектированию решения,
архитектор решений должен поработать с владельцем продукта и изучить пользовательскую аудиторию, проводя интервью и опросы, а также собрав обратную
Построение расширяемой и future-proof архитектуры 91
связь по имитации фронтенд-интерфейса. Он должен понимать ограничения
пользователей и предоставить им необходимые вспомогательные средства.
При запуске продукта команда должна запланировать A/B-тестирование, в ходе
которого небольшая часть пользователей получает доступ к новым возможностям, и ее реакции анализируются. A/B-тестирование сравнивает две версии
приложения, оценивает их производительность и определяет предпочтительный
вариант. Для улучшения дизайна в работающем приложении должен быть преду
смотрен механизм непрерывной обратной связи (в виде формы для заполнения
или службы поддержки пользователей).
По мере развития пользовательской базы архитектура должна быть способна
справляться с ростом требований. Для этого она должна быть расширяемой
и защищенной от устаревания, адаптируемой к будущим изменениям (futureproof). Давайте посмотрим, как обеспечить жизнеспособность архитектуры
в долгосрочной перспективе.
Построение расширяемой и future-proof
архитектуры, подходящей для повторного
использования
Компании развиваются по мере роста; приложения масштабируются с учетом
растущей пользовательской базы и дополняются новыми возможностями для
получения конкурентных преимуществ. Архитектура решения должна быть расширяемой и достаточно гибкой для изменения существующей или добавления
новой функциональности.
Чтобы добиться расширяемости решения, его архитектор должен использовать
слабосвязанные архитектуры везде, где это возможно. На высоком уровне ослаблению связей между модулями или приложениями может способствовать
создание RESTful-архитектуры или архитектуры на базе очереди. О других
разновидностях архитектур вы подробнее узнаете в главе 4 «Паттерны проектирования архитектур решений». В этом разделе концепция архитектурной
гибкости будет рассмотрена на простом примере.
Чтобы выделить в приложении модули, организации часто стараются построить
платформу для разных видов функциональности и запустить их в виде отдельных
приложений. Такое возможно, только если архитектура является подходящей
для повторного использования.
На рис. 2.12 изображена архитектура на базе API в приложении интернет-магазина. Она включает независимые сервисы (каталога товаров, заказов, платежей,
доставки), в нужный момент используемые приложением конечного пользователя. Клиент использует мобильные и браузерные приложения для размещения
заказа на сайте. Таким приложениям нужны сервис каталога товаров, чтобы
клиент мог выбрать товары на сайте, сервис заказов для оформления покупки
и сервис платежей для обработки оплаты.
92
Глава 2. Принципы проектирования архитектур решений
БД складских
запасов
Сервис каталога товаров
Веб-приложение
и браузер
Сервис доставки
БД
заказов
Сервис заказов
API бонусов
Приложение
для точки продаж
БД
платежей
Сервис платежей
Рис. 2.12. Расширяемая архитектура на базе API
В свою очередь, сервис каталога товаров и сервис заказов взаимодействуют
с сервисом доставки для отправки заказанных товаров клиенту. С другой
стороны, физические магазины используют системы точек продаж, в которых
представитель клиента сканирует штрихкоды, размещает заказы по поручению
клиента и получает платежи. Сервис доставки в этом случае не нужен, так как
клиент забирает товар в магазине.
На рис. 2.12 представлен API бонусов, используемый для интеграции сторонних API. Такая архитектура позволяет расширить текущее решение для интеграции API, предназначенных для удержания клиентов, и привлечения новых
клиентов за счет предоставления различных бонусов при покупке. Как видно
из диаграммы, сервисы платежей используются при заказах как на сайте, так
и в магазине. Другой сервис может повторно использовать сервис платежей,
если организация захочет принимать платежи для сервиса подарочных карт,
сервисов доставки продуктов и т. д.
Расширяемость и возможность повторного использования не ограничиваются
уровнем проектирования сервисов — они уходят глубоко на уровень API, где
архитектор продукта должен применять концепции объектно-ориентированного
анализа и проектирования (ООАП) — такие, как наследование — для создания
фреймворка API. Фреймворк может расширяться и повторно использоваться
для добавления новой функциональности в тот же сервис.
Архитектурная интероперабельность и портируемость
93
ООАП — фундаментальный метод программной инженерии, который помогает
разработчикам более эффективно планировать и моделировать приложения,
обеспечивая модульность, масштабируемость и удобство обслуживания
продукта.
Чтобы можно было расширить функциональность приложения, оно должно
бесшовно интегрироваться с другими продуктами, в которых может работать
с более широким набором данных и операций. Обеспечение совместимости
приложения с экосистемой помогает добавлять новые возможности с использованием смежных приложений. В следующем разделе создание совместимой
архитектуры рассматривается более подробно.
Архитектурная интероперабельность
и портируемость
Архитектурная интероперабельность и портируемость — важнейшие параметры современной программной архитектуры, гарантирующие, что приложения
будут работать в разных средах и бесшовно взаимодействовать с другими
системами.
Интероперабельность приложений
Интероперабельностью называется способность одного приложения взаимодействовать с другими по стандартному формату или протоколу. Часто приложение должно взаимодействовать с различными вышележащими системами
для потребления данных и нижележащими — для поставки данных, поэтому
важно организовать эти взаимодействия предельно гладко.
Например, приложение интернет-магазина должно работать с другими приложениями в экосистеме управления цепочкой поставок. К числу таких приложений относятся корпоративные приложения планирования ресурсов, а также
приложения, которые управляют жизненным циклом перевозок, хранят информацию о транспортных компаниях, управляют заказами, складскими запасами
и персоналом.
Чтобы обеспечить сквозной путь от клиента к получению товара, все приложения
должны обмениваться данными без каких-либо проблем. Это актуально и для
приложений из многих других отраслей, будь то здравоохранение, производство
или телекоммуникации.
Архитектор решений должен учитывать интероперабельность приложений
в процессе проектирования. Для этого он выявляет зависимости между системами и работает с ними. Необходимым условием интероперабельности является
единообразное взаимодействие между системами без дополнительных усилий
по отправке данных, что обеспечивает значительную экономию.
94
Глава 2. Принципы проектирования архитектур решений
Объем отправки и получения данных в каждой отрасли свой, и его необходимо
понимать и учитывать. В общем случае при проектировании программных
систем лучше выбрать популярный формат (например, JSON или XML) для
разных приложений, чтобы они взаимодействовали друг с другом. Оба формата
поддерживаются в современных RESTful-API и микросервисных архитектурах
по умолчанию.
Портируемость приложений
Портируемость системы позволяет приложению работать в разных средах без
изменений (или с минимальными изменениями). Любое приложение должно
работать с разными операционными системами и оборудованием.
Технологии стремительно развиваются, выпускаются новые версии языков,
платформ разработки и операционных систем. Необходимо позаботиться о том,
чтобы приложение могло приспособиться к таким изменениям. Мобильные
приложения стали неотъемлемой частью любого системного решения и должны быть совместимы с основными платформами мобильных операционных
систем — таких, как iOS и Android.
На этапе проектирования архитектор решений должен выбрать технологию,
которая обеспечит требуемый уровень портируемости приложения. Например,
если вы собираетесь развернуть свое приложение в разных операционных системах, подойдет такой язык, как Java, так как он поддерживается всеми операционными системами и приложение сможет работать на другой платформе без
необходимости портирования. Для мобильных приложений архитектор может
выбрать фреймворк на базе JavaScript (такой, как React Native), который обес
печит возможность кроссплатформенной мобильной разработки.
Интероперабельность улучшает расширяемость системы, а портируемость
увеличивает возможности использования приложения. Обе характеристики
являются критическими для дизайна приложения и могут создавать экспоненциальные затраты, если архитектор не позаботился о них в ходе проектирования.
Архитектор должен тщательно проработать их на уровне отраслевых требований
и системных зависимостей.
Для сокращения количества ошибок и повышения эффективности чрезвычайно
важна автоматизация. Эта тема рассматривается в следующем разделе.
Повсеместное применение автоматизации
Большинство инцидентов происходит из-за человеческих ошибок, которых можно избежать благодаря автоматизации. Автоматизация не только эффективно
обрабатывает задачи, но и повышает производительность и экономит затраты.
Любая повторяемая задача может быть автоматизирована для высвобождения
ценных человеческих ресурсов, чтобы участники команды могли уделять время
более интересной работе и сосредоточиться на решении реальных задач.
Повсеместное применение автоматизации
95
y
y
y
y
y
В ходе проектирования решения подумайте, что можно автоматизировать. Рассмотрите возможность автоматизации любых повторяемых задач. Попробуйте
автоматизировать следующие компоненты.
y Тестирование приложения: приложение следует тестировать каждый раз,
когда вносятся изменения. Это необходимо, чтобы убедиться, что они ничего не нарушили. Кроме того, ручное тестирование отнимает очень много
времени и требует значительных ресурсов. Автоматизация повторяемых
тестовых сценариев способствует ускорению разработки и запуска продукта. Автоматизируйте тестирование на продакшен и используйте методы
скользящего (rolling) развертывания — такие, как канареечное и A/Bтестирование — при публикации изменений. Канареечное тестирование
подразумевает выпуск изменений для небольшой группы пользователей,
которые оценивают их и выявляют проблемы до полноценного релиза; такой
метод выступает в качестве системы раннего оповещения о потенциальных
проблемах. При A/B-тестировании сравниваются две версии приложения
и принимается решение (на основе данных) о том, какая из них лучше подходит пользователям.
y Инфраструктура IT: для автоматизации инфраструктуры можно воспользоваться скриптами из категории «инфраструктура как код» — например,
Ansible, Terraform или Amazon CloudFormation. Автоматизация инфраструктуры позволяет создавать среды за считаные минуты, а не дни. Автоматизация
инфраструктуры как кода помогает избежать ошибок конфигурации и создает
точную копию среды.
y Журналы, мониторинг и оповещения: система мониторинга исключительно важна. Если вы хотите быть уверены, что все компоненты приложения
работают правильно, и проактивно исправлять любые проблемы, вам стоит
вести постоянный мониторинг всего, что только можно. В очень больших
системах возможен только автоматизированный мониторинг. Чтобы знать,
что приложение работает гладко и так, как предполагалось, вся деятельность
по мониторингу и ведению журналов должна быть автоматизирована. Кроме
того, на основании данных мониторинга могут выполняться автоматизированные действия — например, масштабирование системы или оповещение
команды для принятия мер.
y Автоматизация развертывания: развертывание — неоднократно повторяемая
операция, которая занимает очень много времени и во многих сценариях
реального времени задерживает итоговый запуск. Автоматизация пайплайна
развертывания за счет непрерывной интеграции и непрерывного развертывания (CI/CD) поможет придерживаться методологии Agile и быстро обновлять
функциональность продукта с частыми запусками. CI/CD помогает вносить
в приложение небольшие поэтапные изменения.
y Автоматизация безопасности: занимаясь автоматизацией, не забудьте
об автоматизации безопасности. Если кто-то попытается взломать ваше
96
Глава 2. Принципы проектирования архитектур решений
приложение, вы должны немедленно узнать об этом и действовать быстро.
Также желательно обеспечить превентивные меры, автоматизировав обработку всего входящего или исходящего трафика на границе системы и установив
оповещения для подозрительной активности.
Автоматизация помогает архитектору достичь уверенности в том, что продукт
функционирует без проблем. При проектировании приложения всегда мыслите
с точки зрения автоматизации и относитесь к ней как к одному из важнейших
параметров архитектуры. Автоматизация более подробно рассматривается
в главе 9 «Операционное совершенство».
Планирование непрерывности бизнеса
Существует риск ситуаций, когда весь регион, в котором находится ваш датацентр, окажется неработоспособным из-за массовых отключений электричества,
землетрясения, наводнения или атаки злоумышленников, но глобальный бизнес
должен продолжить работу. Для таких случаев у вас должен быть план аварийного восстановления, предусматривающий обеспечение непрерывности бизнеса
путем подготовки достаточных ИТ-ресурсов в другом регионе (а возможно,
в других странах и даже на других континентах), чтобы бизнес мог быстро восстановиться и продолжить работу либо вообще обойтись без простоев.
В ходе планирования аварийного восстановления архитектор решений должен
понимать метрики RTO и RPO, используемые организацией. RTO (Recovery
Time Objective) определяет, какую продолжительность простоя может позволить
себе бизнес без значительных последствий; RPO определяет, какую часть данных
организация может позволить себе потерять. Сокращение величин RTO и RPO
означает увеличение затрат, поэтому необходимо понимать, является ли простой критически важным для конкретного бизнеса и требует ли минимальных
значений RTO и RPO. Например, приложение для биржевой торговли не может
позволить себе потерять даже одну точку данных, а приложение для управления
железнодорожными сигналами не может простаивать ни секунды, потому что
от этого зависят жизни людей.
На рис. 2.13 изображена многоузловая архитектура аварийного восстановления. Основной дата-центр находится в Ирландии (Европа), а узел аварийного
восстановления — в штате Вирджиния (США), где для хостинга используется
публичная облачная платформа AWS. В таком случае бизнес сможет продолжить
работу, даже если что-то произойдет в европейском регионе или на публичной
облачной платформе. Тот факт, что план аварийного восстановления базируется
на многоузловой модели для достижения минимальных RTO и RPO, означает
отсутствие простоев и потерь данных.
Ниже перечислены самые распространенные планы аварийного восстановления. Все они будут рассмотрены в главе 11 «DevOps и фреймворк архитектуры
решений».
Планирование непрерывности бизнеса
Облако AWS
97
Локальный узел
Северная Вирджиния (США)
Route 53
Ирландия (Европа)
Кластер серверов Amazon EC2
Парк веб-серверов
Веб-серверы
Кластер серверов Amazon EC2
Парк серверов приложений
Серверы приложений
Amazon RDS
Репликация
данных
База данных
Рис. 2.13. Гибридная многоузловая архитектура аварийного восстановления
y
y Резервное копирование и хранение: это наименее затратный план, но зна-
y
y
y
чения RTO и RPO в нем максимальные. В этом плане все машинные образы
серверов и снимки баз данных должны храниться на узле аварийного восстановления. При возникновении аварийной ситуации команда попытается
восстановить отказавший узел из резервной копии.
y Облегченная версия: в этом плане все машинные образы серверов хранятся
в резервной копии, а на узле аварийного восстановления поддерживается
небольшой сервер базы данных с непрерывной синхронизацией данных
с ведущего узла. Другие критические сервисы — такие, как Active Directory —
могут работать в малых экземплярах. В случае аварии команда пытается
восстановить работу сервера из образа и масштабировать базу данных. Облегченная версия обходится дороже, но имеет более низкие RTO и RPO по
сравнению с резервным копированием и хранением.
y Теплый резерв: в этом плане все экземпляры серверов приложений и баз
данных (работающих на пониженной емкости) на узле аварийного восстановления продолжают синхронизироваться с ведущим узлом. В случае аварии
команда пытается масштабировать все серверы и базы данных. Теплый резерв
обходится дороже облегченной версии, но имеет более низкие RTO и RPO.
y Многоузловая архитектура: самый затратный план с близкими к нулю
значениями RTO и RPO. В этом плане на узле аварийного восстановления
поддерживается реплика ведущего узла равной емкости, которая активно
обслуживает пользовательский трафик. В случае аварии весь трафик перенаправляется в другую локацию.
98
Глава 2. Принципы проектирования архитектур решений
Нередко организации выбирают менее затратный вариант аварийного восстановления, но при этом очень важно провести тестирование, чтобы убедиться
в работоспособности средств обработки отказов. Операционное совершенство
должно стать одним из пунктов контрольного списка: необходимо гарантировать
непрерывность бизнеса в процессе восстановления после сбоев. Очень важно
обеспечить также работу приложения в продакшен-среде и его обслуживание
(поддержку) в течение многих лет. В следующем разделе рассматриваются принципы, которые делают приложение удобным в обслуживании и эксплуатации.
Проектирование с учетом эксплуатации
Операционное совершенство (operational excellence) может выделить ваше приложение на фоне конкурентов за счет предоставления услуг высокого качества
с минимальными простоями. Проактивное операционное совершенство также
помогает повысить производительность службы поддержки и инженерных
команд. Удобство обслуживания, или сопровождаемость (maintainability), неразрывно связано с операционным совершенством. Простота обслуживания
приложения помогает сократить затраты, избежать ошибок и получить конкурентное преимущество.
Архитектор решений должен проектировать дизайн продукта с учетом операционного совершенства, включая способы развертывания рабочей нагрузки, обновления и долгосрочной работы. Планирование ведения журналов, мониторинга
и оповещений очень важно для сохранения информации обо всех инцидентах
и быстром принятии мер в целях лучшего взаимодействия с пользователем.
Применяйте автоматизацию везде, где возможно, — как при развертывании
инфраструктур, так и при изменении кода приложения, — чтобы избежать
человеческого фактора.
При проектировании дизайна очень важно использовать методы развертывания и стратегию автоматизации, так как это позволит сократить время вывода
новых изменений на рынок без влияния на текущую эксплуатацию. Планирование операционного совершенства должно учитывать вопросы безопасности
и комплаенс, так как требования нормативных документов могут изменяться
со временем и приложение должно им соответствовать.
Обслуживание может быть как проактивным, так и реактивным; например, при
выходе новой версии операционной системы можно запланировать немедленную смену платформы для модернизации приложения или же организовать
мониторинг работоспособности системы и дождаться завершения срока жизни
продукта перед внесением каких-либо изменений. В любом случае изменения
должны вноситься инкрементно, с возможностью отката. Для применения
таких изменений можно автоматизировать весь процесс, создав пайплайн CI/
CD. Для запуска можно запланировать A/B-тестирование или сине-зеленое
развертывание1.
1
Процесс развертывания обновлений без перерывов в обслуживании. — Примеч. перев.
Преодоление архитектурных ограничений
99
Чтобы обеспечить готовность продукта к эксплуатации, при проектировании
архитектуры необходимо предусмотреть соответствующие документы и механизмы обмена знаниями — например, ранбук (пошаговые инструкции по
выполнению типовых задач) и плейбук (последовательность действий при
реагировании на типовые инциденты). Это позволит быстро отреагировать на
возможные инциденты. Используйте анализ первопричин при составлении отчетов, чтобы определить, почему возникла проблема, и принять меры к тому,
чтобы она не повторялась.
Операционное совершенство и поддержка — нескончаемый процесс; каждое
событие и отказ в ходе эксплуатации дают возможность внести улучшения на
основе опыта прошлых ошибок. Анализируйте операции и сбои, экспериментируйте и совершенствуйтесь. Эти вопросы более подробно рассматриваются
в главе 9 «Операционное совершенство».
В главе 1 «Архитекторы решений в организациях» вы узнали об ограничениях,
которые архитектору приходится учитывать и баланс которых необходимо
выдерживать. Ограничения — один из важнейших принципов, который будет
рассмотрен в следующем разделе.
Преодоление архитектурных ограничений
При проектировании архитектуры приложения приходится учитывать основные
ограничения: по затратам, времени, бюджету, объему поставки, графику и ресурсам. При проектировании решений важно продумать, как эти ограничения
преодолевать. Рассматривайте ограничения не как препятствия, а как вызовы,
с которыми необходимо справиться, — ведь вызовы всегда подталкивают к инновациям.
Архитектор решений должен определять допустимые компромиссы касательно
ограничений. Например, затраты на высокопроизводительное приложение растут, если приходится добавлять кэширование на нескольких уровнях архитектуры. Тем не менее в отдельных случаях затраты важнее производительности;
чаще всего это касается систем для внутренних пользователей, в которых производительность напрямую не влияет на доход компании. Иногда занять долю
рынка важнее, чем запускать полнофункциональный продукт, и приходится
выбирать между широтой охвата и скоростью выпуска. В таких сценариях можно
выбрать модель минимально жизнеспособного продукта, или MVP (Minimum
Viable Product); вы больше узнаете о нем в следующем разделе.
Технологические ограничения особенно актуальны в крупных организациях,
так как вносить изменения в сотни систем может быть непросто. При проектировании приложений рекомендуется использовать самую распространенную
в организации технологию. Кроме того, необходимо убедиться, что приложение
способно обновляться, если будут внедрены новые технологии, и что к нему
можно подключать компоненты, построенные на другой платформе.
100
Глава 2. Принципы проектирования архитектур решений
Модель RESTful-сервисов удобна, если командам разработки разрешается применять любую технологию. Достаточно предоставить URL-адрес, по которому
будут доступны сервисы. Даже унаследованные системы (например, мейнфреймы) могут быть интегрированы в новую систему при помощи API-обертки, и это
помогает справляться с технологическими сложностями.
В этой книге вы узнаете больше о том, как преодолеть различные архитектурные
ограничения. В этом помогает, в частности, метод MVP, благодаря которому
можно построить продукт, ориентированный на клиента.
Метод MVP
Чтобы решение было успешным, всегда ставьте клиента на первое место. Исходите из его потребностей: определите, что для него важно, и планируйте поставку решения адаптивно.
MVP — стратегия разработки, используемая для создания новых продуктов или
веб-сайтов с минимальной функциональностью, необходимой для удовлетворения первых пользователей и проверки концепции продукта на ранней стадии
разработки. В этом методе исходная версия продукта включает только базовую
функциональность, которая позволяет развернуть продукт. Его цели — быстро
предоставить ценность для клиента, минимизировать затраты на разработку
и максимально быстро получить обратную связь от клиентов, чтобы вносить
дальнейшие изменения и совершенствовать продукт.
В одном из популярных методов расстановки приоритетов в списке требований
клиентов — MoSCoW — требования делятся на следующие категории.
y
y Необходимые (Must have): требования, критичные для клиентов, без которых
y
y
y
запуск продукта невозможен.
Желательные
(Should have): требования, соответствие которым очень желаy
тельно для клиентов, когда они начнут пользоваться приложением.
y Возможные (Could have): требования, которым было бы неплохо соответствовать, но несоблюдение которых не повлияет на желаемую функциональность приложения.
y Избыточные (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. Миграция на облачные платформы
y
y
y
y
y
y
y
y
y
y
В этой главе рассматриваются следующие темы.
y Публичные, частные и гибридные облачные платформы.
y Архитектура решения в публичном облаке.
y Облачно-ориентированные архитектуры.
y Создание стратегии облачной миграции.
y Выбор облачной стратегии.
y Последовательность действий при облачной миграции.
y Оптимизация приложений на облачных платформах.
y Создание гибридной облачной архитектуры.
y Мультиоблачные решения.
y Реализация CloudOps.
К концу этой главы вы узнаете о преимуществах облачных платформ и разберетесь в различных стратегиях и последовательности действий при облачной
миграции. Также вы узнаете о гибридных облачных архитектурах, мультиоблачных решениях и реализации CloudOps.
Публичные, частные и гибридные
облачные платформы
Существуют три разновидности облачных моделей: публичные, частные и гибридные.
Публичные облачные платформы строятся на стандартной модели вычислений,
в которой поставщик сервисов предоставляет клиентам онлайн-доступ к различным ресурсам (виртуальным машинам, приложениям, пространству хранения
и т. д.). В модели облачных вычислений провайдер публичной облачной платформы предоставляет по требованию доступ к ИТ-ресурсам (серверам, базам данных,
сети, хранилищу данных), которые могут использоваться организациями через
защищенные веб-интерфейсы или при помощи специальных приложений через
интернет. Такие облачные сервисы предлагают модель оплаты по факту потреб
ления, и в большинстве случаев клиент платит только за сервисы, которые он
реально использует; это снижает его затраты за счет оптимизации ИТ-ресурсов.
Публичные облачные платформы можно рассматривать как аналог модели
электроснабжения: вы включаете свет и платите только за фактически потребленное количество. Как только свет выключается, вы перестаете платить
за него. Эта модель избавляет потребителя от сложных задач: генерирования
энергии турбинами, обслуживания системы и формирования инфраструктуры.
Весь сервис используется по упрощенной схеме.
Кроме снижения затрат, основные провайдеры публичных облачных платформ (такие, как AWS, GCP, Microsoft Azure, Alibaba и Oracle Cloud Platform
(OCP)) способствуют инновациям за счет расширения своих технологических
Архитектура решения в публичном облаке
105
платформ через облако. Эти поставщики отработали масштабируемость и создание перспективных архитектур на основе машинного обучения и аналитики.
Публичные облачные платформы предоставляют доступ к этим передовым
технологиям и возможность использовать их для улучшения проектируемых
архитектур.
Частные (или локальные) облачные платформы регистрируются на одну
конкретную организацию, которая становится их владельцем. Частные облака используются как реплики или расширения существующих дата-центров
компании. В отличие от них, публичные облачные платформы предлагают
совместную аренду; это означает, что виртуальные серверы нескольких клиентов используют один физический сервер. Впрочем, они также могут назначать
выделенные физические серверы, если это понадобится клиенту по условиям
лицензии или комплаенса.
Третью модель — гибридную — выбирают крупные корпорации, которые
перемещают свою рабочую нагрузку из локальной среды в облако. При этом
у них остается старое приложение, которое невозможно переместить в облако
напрямую, или, возможно, лицензированное приложение, которое по условиям
лицензии должно оставаться локальным, или из-за требований комплаенса приходится осуществлять локальную защиту данных. Таким образом, компания
вынуждена поддерживать частичную локальную среду и перемещать другие
приложения на публичную облачную платформу. Иногда организация переносит в облако среды тестирования и разработки, оставляя продакшен-среды
локально. Гибридная модель может изменяться в зависимости от облачной
стратегии организации.
Так как на рынке действуют разные облачные провайдеры, появляется тенденция
к мультиоблачным решениям. В этих решениях компании распределяют свою
рабочую нагрузку между разными провайдерами публичных облачных платформ, чтобы пользоваться сильными сторонами каждой облачной технологии
или предоставить своей команде выбор в зависимости от ее набора навыков.
В следующем разделе мы подробнее рассмотрим публичные облачные технологии и разберемся, как они становятся важнейшей технологической платформой
для бизнеса.
Архитектура решения в публичном облаке
Архитектура решений в облаке начинает играть все более важную роль. Сейчас
она фактически стала «новой нормой», и все больше компаний решают перевести на нее свою рабочую нагрузку. Публичные облачные платформы стали
критическим фактором, питающим рост стартапов, так как нужны лишь небольшие начальные инвестиции вместо значительных затрат на дорогостоящие
локальные решения. Это позволяло организациям проводить эксперименты,
быть адаптивными и внедрять инновации.
106
Глава 3. Миграция на облачные платформы
Самое замечательное в архитектуре облачных вычислений заключается в том,
что они обеспечивают сквозное представление всех архитектурных компонентов,
необходимых для управления всей средой решений, включая фронтенд-платформы, платформы разработки приложений, серверы, хранилища данных, базы
данных, автоматизацию, поставку и сети.
В следующем разделе архитектура публичных облачных платформ рассматривается более подробно.
Публичная облачная архитектура
Стандартное определение публичной облачной архитектуры — полностью
виртуализированная среда, доступная по сети интернет и через частную сеть.
Однако поставщики таких облачных платформ в последнее время стали предлагать локальные физические инфраструктуры, чтобы стимулировать принятие гибридных облачных решений. Публичные облачные платформы предоставляют мультитенантную модель (совместную аренду), при которой
ИТ-инфраструктура — например, хранилища данных и вычислительные мощности — совместно используется разными клиентами; при этом она изолируется на
программном и логическом сетевом уровне, и рабочие нагрузки разных клиентов
не мешают друг другу. Организации также могут обеспечивать изоляцию сетевого
уровня в публичном облаке, чтобы создать собственный виртуальный частный
облачный аналог логического дата-центра. Для удовлетворения нормативных
требований организаций публичные облачные платформы также предоставляют
выделенные физические экземпляры; они бывают доступны онлайн, но этот
вариант встречается не так часто.
Публичные облачные хранилища обеспечивают высокую устойчивость и доступность за счет создания модели избыточности, использующей несколько
дата-центров и надежный механизм репликации данных. Это способствует достижению архитектурной устойчивости и простой масштабируемости.
Существуют три основные разновидности моделей публичных облачных вычислений (рис. 3.1). Для сравнения на диаграмме также представлены локальные
решения.
y
На рис. 3.1 можно сравнить обязанности клиента в локальных средах с моделями
облачных вычислительных сервисов. В локальной среде клиенту приходится
управлять всем, тогда как в модели облачных вычислений клиент может доверить часть своих обязанностей провайдеру и сосредоточиться на потребностях
бизнеса. Ниже перечислены высокоуровневые подробности сервисов, предоставляемых разными моделями облачных вычислений.
y IaaS (Infrastructure as a Service, «инфраструктура как сервис»): в этой модели
облачный провайдер предоставляет инфраструктурные ресурсы (например,
серверы для вычислений, сетевые компоненты, пространство для хранения
данных) в виде управляемых сервисов. Это позволяет клиентам пользоваться
Архитектура решения в публичном облаке
107
y
y
ИТ-ресурсами, не беспокоясь о лишних затратах на поддержание работы
дата-центра (нагрев и охлаждение, монтирование, физическая безопасность
и т. д.).
y PaaS (Platform as a Service, «платформа как сервис»): модель PaaS добавляет
уровень, на котором облачный провайдер берет на себя управление ресурсами,
необходимыми для платформы разработки: операционной системой (ОС),
поддержкой и обновлением программного обеспечения, а также ресурсами
инфраструктуры. Модель PaaS помогает команде сосредоточиться на написании бизнес-логики и на работе с данными. Разработчики избавлены от
хлопот с поддержкой платформы.
y SaaS (Software as a Service, «программное обеспечение как сервис»): модель
SaaS добавляет дополнительный уровень абстракции поверх моделей PaaS
и IaaS. На этом уровне облачный провайдер или разработчик ПО предоставляет готовые к использованию программы, а вы платите за сервис. Пример:
сервисы электронной почты, такие как Gmail, Yahoo Mail, AOL и т. д., где вы
получаете собственное пространство для сообщений как сервис и не нужно
беспокоиться об используемых приложениях или инфраструктурах.
Четвертая, еще только формирующаяся, модель FaaS (Function as a Service,
«функция как сервис») становится популярной при построении бессерверных
архитектур с использованием сервисов, включая AWS Lambda. Бессерверная
архитектура более подробно рассматривается в главе 5 «Паттерны проектирования облачно-ориентированных архитектур».
Ниже приведен краткий обзор провайдеров публичных облачных платформ.
Локальная модель
Инфраструктура
как сервис (IaaS)
Платформа
как сервис (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)
с большим объемом учебных ресурсов, чтобы вы могли попробовать и получить
знания в этой области.
Облачно-ориентированный подход позволяет специалистам развивать инновационное мышление и реализовывать свои идеи немедленно, не дожидаясь
завершения длительного цикла инфраструктуры.
При использовании облачных технологий клиентам не нужно планировать
избыточную емкость для обработки пиковых нагрузок (например, периода
праздничных покупок для розничной торговли); доступная эластичность
мгновенно предоставит ресурсы для повышенного спроса. Это значительно
экономит затраты и улучшает пользовательские взаимодействия. Чтобы не
отстать от конкурентов, организациям приходится действовать быстро и нестандартно.
y
y
y
y
y
Облачные платформы позволяют предприятиям быстро развернуть свою
инфраструктуру по всему миру и получить доступ к технологиям, которые ранее были им недоступны. Некоторые передовые технологии из этой
категории:
y большие данные и аналитика;
y машинное обучение и ИИ;
y интернет вещей (IoT);
y блокчейн;
y генеративный ИИ.
Построение архитектуры решения для облака отличается от работы архитектора для обычных организаций. При переходе в облако необходимо развить
облачное мышление и понять, как пользоваться встроенными возможностями
облачных платформ. Для облачного мышления следует руководствоваться
моделью оплаты по факту потребления, а это означает, что вы должны следить
за правильной оптимизацией рабочей нагрузки и запускать серверы, только
когда это необходимо.
При проектировании для облачных платформ архитектор решений должен
иметь целостное представление обо всех компонентах, относящихся
к производительности, масштабированию, высокой доступности, аварийному
восстановлению, отказоустойчивости, безопасности и автоматизации.
Другие области оптимизации — облачно-ориентированные механизмы мониторинга и оповещений. Возможно, вам не придется переносить в облако существующие сторонние средства мониторинга с локальных площадок, так как
облачные средства мониторинга будут более эффективными и избавят вас от
затрат на дорогостоящие сторонние лицензионные программы. Кроме того, у вас
появляется возможность за считаные минуты провести развертывание в любой
110
Глава 3. Миграция на облачные платформы
части мира. Не ограничивайтесь конкретным регионом; используйте модель
глобального развертывания для построения более эффективных механизмов
высокой доступности и аварийного восстановления.
Облачные платформы предоставляют отличные возможности для автоматизации; по сути, с ними можно автоматизировать все. Автоматизация сокращает
ошибки, ускоряет выход на рынок и дает значительную экономию за счет эффективного использования человеческих ресурсов и избавления сотрудников
от выполнения однообразных и скучных операций.
Облачные платформы используют модель разделения ответственности, в которой облачные провайдеры отвечают за защиту физической инфраструктуры.
При этом безопасность приложения и его данных полностью зависит от клиента.
Следовательно, очень важно изолировать вашу среду и осуществлять контроль
безопасности, используя облачные инструменты мониторинга, оповещений
и автоматизации.
Проектирование облачно-ориентированных
архитектур
В разных организациях могут существовать разные мнения по поводу облачноориентированных архитектур, но все сходятся на том, что облачно-ориентированное мышление направлено на максимально эффективное использование
всех облачных возможностей. Истинная облачно-ориентированная архитектура
означает проектирование приложения, начиная с самых его основ, с учетом облачной специфики.
y
y
y
y
y
Облачно-ориентированное проектирование не означает хостинга приложения на
облачной платформе; оно направлено на эффективное использование сервисов
и возможностей, предоставляемых такой платформой. В частности:
y контейнеризация монолитной архитектуры в микросервисе и создание пайплайна CI/CD для автоматического развертывания;
y построение бессерверного приложения с такой технологией, как AWS Lambda
FaaS и Amazon DynamoDB (управляемая база данных NoSQL в облаке);
y создание бессерверных озер данных — например, с использованием Amazon
S3 (управляемого сервиса хранения объектов), AWS Glue (управляемого
кластера Spark для ETL) и Amazon Athena (управляемого кластера Presto
для ситуативных запросов);
y использование облачно-ориентированного сервиса мониторинга и ведения
журналов (например, Amazon CloudWatch);
y использование облачно-ориентированного сервиса аудита (например, AWS
CloudTrail).
На следующей диаграмме (рис. 3.2) представлен пример облачно-ориентированных бессерверных архитектур для приложения микроблогов.
Архитектура решения в публичном облаке
111
Шлюз Amazon API
Пользовательский запрос
Облако AWS
Amazon API Gateway
Amazon S3
AWS Lambda
Проверка пользователя
AWS Lambda
Профиль пользователя
AWS Lambda
Страница блога
Amazon
DynamoDB
Рис. 3.2. Облачно-ориентированная архитектура приложения
для ведения микроблогов
На этой диаграмме представлено использование облачно-ориентированных
бессерверных сервисов в облаке AWS. Здесь Amazon Route 53, управляющий
сервисом DNS, осуществляет маршрутизацию пользовательских запросов.
Lambda — сервис для обработки кода проверки пользователя, пользовательских
профилей и страниц блогов. Все ресурсы блогов хранятся в Amazon S3, который управляет сервисами хранения объектов, а все данные пользовательских
профилей хранятся в Amazon DynamoDB — управляемой базе данных NoSQL.
Когда пользователи отправляют свои запросы, AWS Lambda проверяет пользователей и обращается к их профилям, чтобы убедиться, что у них имеется
подписка Amazon DynamoDB; после этого сервис выбирает ресурсы блога
(графику, видео, статическую разметку HTML) из Amazon S3 и отображает их
для пользователя. Такая архитектура может масштабироваться неограниченно,
так как все сервисы являются облачно-ориентированными и управляемыми,
и управлять инфраструктурой не требуется.
Такие критические факторы, как высокая доступность, аварийное восстановление и масштабируемость, обеспечиваются облачно-ориентированными
112
Глава 3. Миграция на облачные платформы
сервисами, чтобы вы могли сосредоточиться на разработке функциональности.
Что касается затрат, вы платите только в том случае, если запрос поступает
приложению блогов. Если никто не просматривает блог ночью, за хостинг
своего кода вы ничего не платите; оплачивается только номинальная стоимость
хранения.
Преимущество облачно-ориентированной архитектуры заключается в том, что
она позволяет командам быстро внедрять инновации и действовать адаптивно.
Она упрощает построение сложных приложений и инфраструктур. Так как
вы занимаетесь исключительно проектированием и построением своих сетей,
серверов, файловых хранилищ и других вычислительных ресурсов, физическую
реализацию можно доверить провайдеру облачных вычислений.
y
y
y
Другие преимущества облачно-ориентированных архитектур.
y Быстрое масштабирование по требованию: вы можете запросить необходимые ресурсы, когда это действительно нужно. Вы платите только за то, что
реально используете.
y Быстрая репликация: «инфраструктура как код» означает, что вы строите
один раз, а потом делаете репликацию. Вместо того чтобы строить инфраструктуру вручную, вы структурируете ее в виде серии скриптов или приложений. Создание инфраструктуры на программном уровне позволяет строить
и перестраивать ее по требованию, когда это понадобится для разработки
или тестирования.
y Простота создания и удаления: в облаке сервисы предоставляются по требованию, поэтому построить большую экспериментальную систему достаточно просто. Она может включать кластер масштабируемых веб-серверов
и серверов приложений, несколько баз данных, терабайты пространства
хранения данных, управляющие приложения и средства мониторинга.
Это все легко убрать после завершения эксперимента и уменьшить таким
образом затраты.
Для облачно-ориентированных архитектур существует много других примеров
в области хранения, сетей и автоматизации. Особенности этой архитектуры
подробно рассматриваются в главе 5 «Паттерны проектирования облачно-
ориентированных архитектур».
В следующем разделе рассматриваются различные стратегии облачной миграции.
Стратегии облачной миграции
y
Выбранная облачная стратегия поможет определить стратегию миграции и расставить приоритеты для приложений. Ниже перечислены некоторые критерии
для запуска стратегий облачной и гибридной миграции:
y дата-центр нуждается в технологическом обновлении;
Стратегии облачной миграции
113
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y у дата-центра истекает срок аренды;
y у дата-центра исчерпаны емкости хранения данных и вычислительные мощности;
требуется модернизация приложения;
освоение передовых технологий: генеративный ИИ, расширенная аналитика,
машинное обучение, IoT и т. д;
требуется оптимизация ИТ-ресурсов для экономии эксплуатационных расходов;
планирование аварийного восстановления и эксплуатационная устойчивость;
использование сети распространения контента (CDN) для веб-сайта;
сокращение исходных капитальных затрат и исключение затрат на обслуживание;
повышение эффективности и производительности труда;
повышение адаптивности бизнеса.
Разные организации применяют разные стратегии, и при переходе на облачные
платформы единственно верного пути не существует. Популярные сценарии
использования — размещение сред разработки и тестирования в облаке, чтобы
у разработчиков была возможность действовать более адаптивно и быстро. Поскольку хостинг веб-приложений в облаке дешевле и проще, компании начинают
использовать облачные платформы для цифровой трансформации, организуя
облачный хостинг своих веб-сайтов и цифровых активов.
Важно не только разработать приложение для веб-браузера, но и убедиться,
что оно доступно на смартфонах и планшетах. Облако упрощает такие преобразования. Обработка данных и аналитика — еще одна область, ради которой
переходят на облачные технологии, поскольку они позволяют быстрее и дешевле
собирать, хранить, анализировать и передавать данные.
Переход на облачные технологии не сводится к выбору платформы, проектированию безопасности и эксплуатации. Помимо технологий, следует учитывать
человеческий фактор, процессы и культуру в компании. Для успеха облачной
миграции необходимо согласовать цели с руководством и обеспечить вовлеченность команды через обучение. Чтобы гарантировать плавный переход на облачную платформу, следует сформировать соответствующее вˆидение в рамках
всей организации.
Часто в проектах миграции применяются сразу несколько стратегий и различные
инструменты. Стратегия миграции влияет на время, которое займет переход,
и способы группировки приложений для процесса миграции. На следующей
диаграмме (рис. 3.3) представлены некоторые часто применяемые стратегии
для миграции существующих приложений в облако.
114
Глава 3. Миграция на облачные платформы
Релокация
Метод переноса
lift-and-shift
Локальное
приложение
Обнаружение
приложений
Вывод из эксплуатации/
сохранение
Рехостинг
Смена платформы
Облачная
ориентация
Проверка и миграция
Облако
Рефакторинг
Повторная покупка
Рис. 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) — быстрый, предсказуемый, повторяемый и экономичный
механизм, что делает его предпочтительным методом миграции на облачные
платформы. Кроме того, рехостинг считается одной из самых быстрых стратегий облачной миграции, при которой сервер или приложение перемещаются
из исходной локальной среды в облако. В процессе миграции в ресурсы могут
вноситься минимальные изменения.
Клиенты часто используют рехостинг, чтобы быстро провести миграцию своих
приложений в облако, а затем, когда ресурсы начнут работать в облаке, сосредоточиться на оптимизации. Этот метод позволяет реализовать экономические
преимущества использования облачных платформ.
y
y
y
Клиенты обычно применяют рехостинг в следующих сценариях:
y создание временной среды для разработки и тестирования;
y выполнение на серверах пакетных программ — например, SAP или Microsoft
SharePoint;
y отсутствие у приложения активной дорожной карты.
Хотя рехостинг предназначен для пакетного ПО и ускоряет переход на облачную
платформу, возможно, для его использования придется обновить нижележащие
платформы приложений (например, операционные системы). В такой ситуации
для облачной миграции можно воспользоваться методом смены платформы.
116
Глава 3. Миграция на облачные платформы
Смена платформы
Проект облачной миграции можно инициировать, когда срок службы версии
ОС, сервера или базы данных подходит к концу, — например, при обновлении
ОС веб-сервера до Microsoft Windows 2022, обновлении базы данных до версии Oracle 23c и т. д. Стратегия смены платформы (replatform) подразумевает
обновление платформы как часть проекта облачной миграции без изменения
архитектуры приложения. В рамках миграции можно обновить ОС или приложение до новой версии.
При использовании стратегии смены платформы может возникнуть необходимость переустановить приложение в среде назначения, что приведет к изменениям в приложении. Тогда нужно тщательно протестировать приложение, чтобы
проверить его эксплуатационную эффективность после миграции.
y
y
y
y
y
y
Смена платформы может быть обусловлена следующими причинами:
y переход с 32-разрядной версии ОС на 64-разрядную;
y изменение ядра базы данных;
y обновление версии приложения;
y обновление ОС;
y обновление ядра базы данных;
y использование преимуществ управляемых сервисов, предоставляемых облачными провайдерами (управляемое хранилище, базы данных, развертывание
приложения, средства управления).
Смена платформы помогает перейти на более продвинутую платформу приложения в процессе миграции в облако. Приложение можно переместить в облако,
если оно развернуто в контейнерах или VMWare.
Рассмотрим теперь стратегию релокации.
Релокация
Приложение может быть развернуто с использованием контейнеров или экземпляров VMWare в локальном дата-центре. Для перемещения таких рабочих
нагрузок в облако используется ускоренная стратегия миграции: релокация
(relocation).
Релокация помогает перемещать сотни приложений за считаные дни. Приложения, базирующиеся на VMWare и контейнерных технологиях, можно релоцировать в облако с минимальными усилиями и сложностью.
Стратегия релокации требует лишь немного времени разработчиков на начальной стадии или наличия плана тестирования и обеспечивает адаптивность и автоматизацию, ожидаемую от облака. Определите существующие
конфигурации и используйте VMotion или Docker для перемещения серверов
в облако. Подробнее о Docker вы узнаете в главе 6 «Факторы производительности».
Стратегии облачной миграции
117
VMotion — технология VMware, известная возможностью живой миграции. Она
позволяет переместить виртуальный экземпляр с одного физического хоста
на другой без прерывания сервиса.
В процессе миграции приложения в облако возникает возможность перестроить
и переработать архитектуру всего приложения, чтобы оно стало более облачно-ориентированным. Это позволит использовать весь потенциал облачных
технологий. Рассмотрим облачно-ориентированный подход более подробно.
Облачно-ориентированный подход
Когда команда решает перейти на облачно-ориентированное решение, в крат
косрочной перспективе это может потребовать больших усилий на начальном
этапе и замедлит миграцию в облако. Однако в долгосрочной перспективе эти
усилия окупятся, когда вы будете пользоваться всеми преимуществами облачных
технологий и внедрять инновации вашей agile-командой.
Облачно-ориентированный подход со временем значительно снижает затраты,
поскольку позволяет оптимизировать рабочую нагрузку за разумную цену при сохранении уровня производительности благодаря модели оплаты за фактическое
использование. Облачно-ориентированный подход включает контейнеризацию
приложения путем его перепроектирования в виде микросервиса или выбора
бессерверного подхода.
Рассмотрим методы рефакторинга и повторного приобретения для облачноориентированной миграции.
Рефакторинг
Рефакторинг (refactoring) подразумевает перепроектирование и переписывание
приложения перед его миграцией в облако, чтобы сделать его облачно-ориентированным. Рефакторинг повышает уровень модульности приложения (например, переходом от монолитной архитектуры к микросервисной). Переход
к микросервисной архитектуре помогает организациям создавать небольшие
независимые команды, которые полностью владеют своей частью кода, и это
способствует повышению скорости инноваций.
Облачно-ориентированные приложения проектируются с расчетом на эффективную работу в облаке. В частности, облачные платформы предоставляют
такие преимущества, как масштабируемость, безопасность, адаптивность
и экономическая эффективность.
Рефакторинг требует больших затрат времени и ресурсов перед миграцией. Этот
подход часто используется в организациях с обширным опытом использования облачных технологий или с высококвалифицированными сотрудниками.
Альтернативный вариант рефакторинга — миграция приложения в облако
с его последующей оптимизацией. Для сокращения накладных расходов на
118
Глава 3. Миграция на облачные платформы
администрирование модульной архитектуры можно использовать облачноориентированные бессерверные технологии.
y
y
y
y
y
y
y
Несколько типичных примеров рефакторинга:
y смена платформы (например, переход с AIX на Unix);
y преобразование традиционной базы данных в облачную;
y замена промежуточного ПО (middleware);
y преобразование монолитной архитектуры приложения в микросервисную;
y переработка архитектуры приложения (например, контейнеризация или
переход к бессерверной архитектуре);
y изменение кода компонентов приложения;
y модернизация хранилищ данных для связывания организаций с клиентами.
Принятие решения о том, следует ли преобразовать приложение к микросервисной архитектуре либо перестроить его для контейнеризации или бессерверной
архитектуры, требует тщательного анализа стратегических целей организации,
необходимых затрат и технических возможностей. Переход к микросервисной
архитектуре улучшает масштабируемость и гибкость, когда каждый сервис разрабатывается, развертывается и масштабируется независимо от других, а это
значительно улучшает долгосрочную адаптивность и эффективность. Однако
такой подход может приводить к серьезному рефакторингу и создавать сложности в координации сервисов и сетевых коммуникаций. С другой стороны,
перестройка архитектуры для перехода на контейнеризацию или бессерверные
модели может оптимизировать текущие операции, сокращать накладные расходы на инфраструктуру и улучшать скорость развертывания, однако требует
исходных вложений в разработку и адаптацию команды.
При принятии решения необходимо учитывать совместимость приложения
с новой архитектурой, опыт команды и потенциальные последствия для производительности и надежности. Микросервисы улучшают изоляцию сбоев
и упрощают более детализированное управление ресурсами, а контейнеризация
и бессерверные архитектуры оптимизируют использование ресурсов и потенциально сокращают затраты. Важно учитывать также факторы безопасности
и комплаенса, поскольку каждый архитектурный стиль подразумевает специ
фические проблемы, которыми необходимо решать проактивно.
Иногда перестройка приложения требует значительных усилий. Вы, как архитектор, должны оценить, позволит ли приобретение продукта SaaS добиться
более высокого коэффициента возврата инвестиций (ROI).
Давайте более подробно рассмотрим стратегию повторного приобретения
(repurchase).
Стратегии облачной миграции
119
Повторное приобретение
Для переноса ИТ-ресурсов и проектов в облако могут понадобиться серверы или
приложения, которые потребуют покупки облачно-совместимой лицензии или
версии. Например, текущая локальная лицензия приложения может потребовать
подтверждения при запуске приложения в облаке.
Существует много вариантов обработки таких сценариев лицензирования.
Можно приобрести новую лицензию и продолжить пользоваться приложением в облаке или же удалить существующую лицензию и заменить ее другой,
предназначенной для облачной платформы. Такая замена может быть частью
предложения SaaS.
Может оказаться, что облачная платформа не решает всех проблем и унаследованное приложение не выигрывает от облачной миграции. А иногда обнаруживаются редко используемые приложения, которые можно удалить.
Рационализация рабочей нагрузки. Рационализация рабочей нагрузки —
стратегический процесс облачной миграции и проектирования архитектур,
направленный на консолидацию похожих сервисов для оптимизации операций
и повышения эффективности. Этот подход включает оценку и слияние
различных систем (например, разных CRM-систем) в единое решение. Его
цель — устранение избыточности, сокращение сложности и оптимизация
ресурсов в ИТ-среде организации.
Во многих компаниях рационализация рабочей нагрузки становится критической инициативой, определяющей решения о том, какие приложения
следует оставить, обновить, удалить или консолидировать. Этот процесс не
только способствует упрощению технологического стека, но и устанавливает соответствие ИТ-ресурсов бизнес-целям организации, гарантируя, что
каждый сервис необходим, эффективен и вносит свой вклад в глобальные
цели организации. При помощи рационализации компании могут создавать
более адаптивные, экономически эффективные и масштабируемые ИТинфраструктуры, которые особенно полезны в контексте облачной миграции
и гибридных облачных архитектур, где эффективность и адаптируемость
играют решающую роль.
В следующем разделе более подробно рассматривается стратегия «сохранение
или вывод из эксплуатации» (retain or retire).
Сохранение или вывод из эксплуатации
При проведении облачной миграции, возможно, будет достаточно переместить
только некоторые приложения. Не исключено, что какие-то приложения нужно
будет сохранить из-за технологических ограничений: например, привязанные
к локальному серверу, который переместить невозможно. С другой стороны,
можно удалить некоторые приложения и заменить их облачно-ориентированными (например, сторонние приложения для мониторинга и оповещения).
Рассмотрим обе стратегии более подробно.
120
Глава 3. Миграция на облачные платформы
Сохранение
В локальной среде могут присутствовать приложения, жизненно важные для
бизнеса, но непригодные для миграции по техническим причинам — например,
потому что ОС/приложение не поддерживается на облачной платформе. В таких
ситуациях приложение не удастся перенести на облачную платформу, но можно
продолжить выполнять его в локальной среде.
Возможно, для таких серверов и приложений будет достаточно провести только
исходный анализ, чтобы определить их пригодность к облачной миграции. Однако у сервера или приложения могут оставаться зависимости с мигрированными
приложениями. А значит, придется поддерживать связь этих локальных серверов
с облачной средой. В разделе «Создание гибридной облачной архитектуры» этой
главы вы больше узнаете о связывании локальных и облачных сред.
Возможно, вы захотите сохранить сложные старые системы в локальной среде
и расставить приоритеты, чтобы их можно было перенести позднее. Однако во
время анализа организации часто обнаруживают приложения, которые не используются, но остаются в системе и потребляют инфраструктурное пространство. Вы можете принять решение об удалении таких приложений. В следующем
разделе стратегия удаления рассматривается более подробно.
Вывод из эксплуатации (удаление)
y
y
y
В процессе миграции на облачную платформу можно обнаружить:
y редко используемые приложения;
y приложения, потребляющие избыточную емкость сервера;
y приложения, в которых больше нет надобности из-за несовместимости с облачной платформой.
В такой ситуации можно удалить существующую рабочую нагрузку и выбрать
другой подход, более облачно-ориентированный.
y
y
y
y
y
Стратегия удаления может применяться к хостам и приложениям, которые
вскоре будут выведены из эксплуатации. Также она может применяться к лишним, избыточным приложениям. В зависимости от бизнес-потребностей такие
приложения могут выводиться из эксплуатации локально, без миграции в облако. К числу хостов и приложений, обычно подходящих для удаления, обычно
относятся:
y локальные серверы и хранилища, предназначенные для целей аварийного
восстановления;
y консолидация серверов для устранения избыточности;
y дубликаты ресурсов, появившиеся из-за слияний и поглощений;
y альтернативные хосты в типичной конфигурации с высокой доступностью;
y инструменты со сторонней лицензией (например, средства мониторинга
и автоматизации рабочей нагрузки), поставляемые с облаком.
Выбор стратегии облачной миграции
121
Во многих проектах миграции применяются сразу несколько стратегий, и для
каждой из них доступны разные инструменты. Стратегия влияет на время,
необходимое для миграции, и на группировку приложений для процесса
миграции. Облачная миграция — подходящий момент для проведения инвентаризации и удаления любых «серверов-призраков», за которые никто не отвечает. В следующем разделе мы сравним облачные стратегии, представленные
в этом разделе.
Выбор стратегии облачной миграции
Выбор правильной стратегии миграции имеет решающее значение для бизнеса. При этом необходимо учитывать действующие ограничения: финансы,
ресурсы, время, квалификацию сотрудников. Усилия, которых требуют стратегии, перечисленные в предыдущем разделе, можно сравнить по следующей
таблице.
Таблица 3.1. Сравнение стратегий облачной миграции
Стратегия
миграции
Описание
Время и затраты
Возможности
оптимизации
Рефакторинг
Изменение архитектуры
приложений на модульную,
чтобы сделать их более облачно-ориентированными
Смена
платформы
Миграция приложений на
обновленную платформу без
изменения базовой архитектуры
Повторная
покупка
Замена текущей среды путем приобретения решения
на основе облака
Рехостинг
Быстрое перемещение приложений в облако без изменения архитектуры
Сохранение
Приложение остается в локальной среде, по крайней
мере на какое-то время
–
Релокация
Быстрое перемещение приложений в облако без их
изменения
–
Удаление
Выявление ресурсов, которые перестали быть полезными, и вывод их из
эксплуатации
–
–
122
Глава 3. Миграция на облачные платформы
y
y
y
y
y
y
y
y
Облачная миграция предоставляет многочисленные преимущества (масштабируемость, гибкость, экономическую эффективность), но она влечет и целый
ряд рисков. Организации должны знать о потенциальных проблемах, чтобы
эффективно бороться с ними. Вот некоторые из возможных рисков.
y Потеря и утечка данных: в процессе миграции может возникнуть угроза
для конфиденциальности данных, если они не будут зашифрованы или ими
будут неправильно управлять. Гарантия целостности и безопасности данных
в процессе миграции — обязательное условие для предотвращения утечек
и несанкционированного доступа.
y Простои: миграция может привести к бездействию системы, которое отра
зится на бизнес-операциях. Планирование и выполнение миграции по этапам
или во время пониженной нагрузки снизит последствия для непрерывности
бизнеса.
y Превышение затрат: без должного планирования и понимания моделей оплаты облачных сервисов организации могут столкнуться с непредвиденными
затратами. Необходимо иметь четкий план и бюджет для процесса миграции.
y Проблемы производительности: приложения могут работать в облаке с пониженной эффективностью из-за различий в архитектуре или непредвиденных
проблем совместимости. После миграции необходимо провести тщательное
тестирование и оптимизацию.
y Недостаток навыков: нехватка опыта работы в облаке может замедлить
процесс миграции и будущую эксплуатацию. Дополнительные затраты на обучение (и, возможно, на привлечение специалистов) могут снизить этот риск.
y Проблемы с совместимостью и интеграцией: обеспечить плавную работу
существующих систем и приложений с облачными сервисами может быть
сложно, так как для этого потребуются надежная интеграция и стратегии
тестирования.
y Комплаенс: соблюдать отраслевые нормативные документы и стандарты
в облачной среде может быть сложнее, особенно если организация работает
в жестко регулируемом секторе.
Привязка
к провайдеру: слишком сильная зависимость от технологий
y
и сервисов конкретного облачного провайдера может создать сложности при
переходе на другого провайдера в будущем, с потенциальными последствиями
для гибкости и экономической эффективности.
Для сокращения рисков, связанных с облачной миграцией, при переносе приложений в облако всегда рекомендуется действовать поэтапно. Чтобы воспользоваться преимуществами экономии, повышения производительности и продуктивности ресурсов, сперва определите приоритеты бизнес-функциональности
и оптимизируйте приложения. Начните с миграции, а на последующих этапах
уже можно заняться оптимизацией. Например, если вы проводите миграцию
приложения, использующего базу данных MS SQL, и заменяете его облачно-ориентированной базой данных (такой, как Amazon Aurora или Azure SQL), лучше
Этапы облачной миграции
123
всего на первом этапе провести миграцию приложения, а затем на втором этапе
заняться миграцией базы данных параллельно с мониторингом рисков и стабильности приложения. Оптимизировать приложение на последующих этапах
можно, используя облачно-ориентированный бессерверный технологический
стек — например, AWS Lambda, Amazon API Gateway или Amazon DynamoDB.
Стратегия миграции должна определяться с расчетом на быстрое выполнение,
чтобы команды могли работать независимо. Она может влиять на другие организационные факторы, например построение инженерной функциональности
в пределах организации вместо передачи на аутсорс. Миграция в облако также
предоставляет отличную возможность для принятия или расширения культуры
DevOps в организации. Эта культура выводит на передний план совместную
работу команд разработки и эксплуатации, оптимизацию рабочих процессов
и повышение эффективности.
Неожиданные преимущества оптимизации рабочих процессов и укрепления
безопасности часто проявляются во время проверки приложений в ходе
подготовки к миграции.
Облачная миграция включает несколько этапов, которые будут рассмотрены
в следующем разделе.
Этапы облачной миграции
В предыдущем разделе вы узнали о разных стратегиях облачной миграции и, возможно, уже начали группировать свои приложения для применения соответствующих стратегий. Эти стратегии объединяются под общей аббревиатурой 7R (от
их английских названий Retain, Retire, Relocate, Rehost, Repurchase, Replatform
и Refactor), и некоторые из них могут стать частью вашего перехода в облако.
Возможно, вам придется провести миграцию и управлять несколькими приложениями в облаке — для этого желательно создать облачный центр компетенций
(CoE, Center of Excellence) и стандартизировать процесс при помощи фабрики
облачной миграции. Облачный CoE включает опытных специалистов из ИТи бизнес-команд в пределах организации; они объединяются в специализированную облачную команду, задача которой — ускорить распространения облачных
знаний в организации. Фабрика облачной миграции определяет миграционные
процессы и инструменты, а также действия, которые необходимо предпринять
в ходе миграции (рис. 3.4).
y
y
y
Как показано на диаграмме, облачная миграция включает следующие этапы.
y Инвентаризация: выявление портфелей облачной миграции и локальных
рабочих нагрузок.
y Анализ: анализ обнаруженных данных и рабочих нагрузок.
y Планирование: разработка стратегии и плана миграции в облако.
124
Глава 3. Миграция на облачные платформы
Планирование
Анализ
Проектирование
Инвентаризация
Локальный
дата-центр
Миграция
Фабрика облачной
миграции
Оптимизация
Публичная
облачная
платформа
Интеграция
Эксплуатация
Проверка
Рис. 3.4. Этапы облачной миграции
y
y Проектирование: проектирование приложения в соответствии с выбранной
y
y
y
y
y
стратегией.
y Миграция: непосредственное выполнение миграции.
y Интеграция: интеграция с другими приложениями и системными зависимостями.
y Проверка: проверка функциональности после миграции.
y Эксплуатация: организация работы в облаке.
y Оптимизация: оптимизация рабочих нагрузок под облачную инфраструктуру.
Одним из начальных шагов в рамках проекта облачной миграции становятся
оценка и назначение приоритетов приложениям для миграции. Для этого
необходимо провести полную инвентаризацию ИТ-ресурсов среды и определить, какие серверы, приложения и бизнес-подразделения доступны для
миграции в облако, назначить приоритеты в плане миграции и определить
стратегию миграции для этих приложений. Рассмотрим каждый шаг более
подробно.
Этапы облачной миграции
125
Инвентаризация
y
y
y
y
y
y
y
y
y
На этапе инвентаризации осуществляются выявление и сохранение подробных
данных о портфеле облачной миграции — например, объем проекта миграции.
Определяются необходимые серверы и приложения портфеля, а также их взаимные зависимости и текущие эталонные метрики производительности. Кроме
того, при определении рабочей нагрузки необходимо иметь хорошее представление о следующих параметрах.
y Хранимые данные: идентификация объема и типа хранимых данных (баз
данных, файлов и т. д.). Например: приложение использует 1 Тбайт блокового
хранилища для операций с базой данных.
y Сетевые конфигурации: понимание топологии сети, включая подсети, файрволлы и балансировщики нагрузки. Например: приложение распределено по
нескольким подсетям с особыми правилами фильтрации трафика.
y Безопасность и комплаенс: документирование политик безопасности, механизмов защиты данных и требований соответствия. Например: приложение
должно соответствовать требованиям GDPR и использовать шифрование
данных при хранении.
y Частота выпуска релизов: определение частоты развертывания новых релизов. Например: график выпуска новых релизов приложения — каждые
две недели.
y Модель DevOps: понимание процессов интеграции и развертывания, используемых инструментов и уровня автоматизации. Например: организация
использует Jenkins для CI/CD с высокой степенью автоматизации пайплайна.
y Путь эскалации: документирование процесса для преодоления инцидентов
и сбоев. Например: идентификация ключевых контактов и процедур на случай
прерывания обслуживания.
y Обслуживание ОС и установка обновлений: понимание того, как и когда
применяются обновления ОС. Например: ежемесячная автоматическая
установка обновлений (или ручное обновление).
y Лицензионные требования: определение всех программных лицензий,
нуждающихся в обслуживании или обновлении. Например: проверка того,
использует ли приложение лицензированное промежуточное ПО, которое
необходимо учесть в облаке.
y Другие связанные ресурсы: выявление дополнительных компонентов, связанных с рабочей нагрузкой (внешних зависимостей, сторонних сервисов,
интегрированных инструментов и т. д.). Например, понимание зависимости
приложения от внешнего платежного сервиса.
Подробная информация помогает не только проектировать целевую облачную
среду и определять затраты, но и выявлять любые проблемы в текущем состоянии приложения, которые должны быть исправлены перед миграцией в облако.
126
Глава 3. Миграция на облачные платформы
Процедура определения портфеля идентифицирует все ИТ-ресурсы, задействованные в проекте облачной миграции, включая серверы и приложения, их
зависимости и метрики производительности.
Также необходимо собрать подробную бизнес-информацию об имеющихся
ресурсах — например, текущее состояние ресурса, цикл обновления приложения, карту приложения и критичность сервера или приложения для
бизнеса. Эти подробности помогут определить стратегию и план миграции.
В большинстве организаций ресурсами занимаются разные бизнес-подразделения и команды. Следовательно, в процессе их определения необходимо
взаимодействовать с разными командами: бизнеса, разработки, дата-центра,
сетей, финансовыми и т. д.
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Важно понимать, что ландшафт определения портфеля зависит от различных
факторов.
y Что уже было перенесено в облако?
y Какие существуют зависимости приложения наряду с ресурсами и активами?
y Какие бизнес-факторы направляют процесс облачной миграции?
y Какова оцениваемая продолжительность всего проекта миграции?
y Сколько этапов должен включать процесс миграции?
Одной из главных проблем в проектах миграции становится определение взаи
мозависимостей между приложениями, особенно связанных с операциями
ввода/вывода (I/O) и коммуникациями. Облачная миграция дополнительно
усложняется расширением организаций из-за слияний, поглощений и роста.
Организации часто не владеют полной информацией, касающейся следующих
параметров:
y количество серверов;
y спецификации серверов (тип и версия ОС, оперативная память, процессор,
диск и т. д.);
y метрики загруженности серверов и метрики производительности;
y зависимости между серверами;
y подробная информация о сети.
Грамотное определение портфеля помогает ответить на следующие вопросы.
y Какие приложения, бизнес-подразделения и дата-центры следует переносить
в облако?
y Насколько хорошо подходят приложения для миграции на облачную платформу?
y Какие известные (и, возможно, неизвестные) риски связаны с миграцией
приложения в облако?
y Какие приоритеты назначить приложениям для миграции?
y От каких других ИТ-ресурсов зависит приложение?
y Каковы наилучшие стратегии миграции для приложения?
Этапы облачной миграции
127
y
y Что лучше — допустить некоторое время простоя или проводить миграцию
y
y
работающего приложения со всеми зависимостями и рисками?
На рынке существуют инструменты, которые помогают автоматизировать
процесс инвентаризации и предоставляют подробную информацию в разных
форматах. Эти инструменты можно классифицировать на основе разных
характеристик: типу развертывания, эксплуатации, поддержке, типу обнаруживаемых данных. Большинство доступных решений можно разделить на две
общие категории:
y агентские решения, требующие установки программного клиента на сервере
для сбора необходимой информации (например, установки агента мониторинга на всех серверах среды для отслеживания метрик производительности,
сбора учетной информации о ПО и системных журналов);
y безагентские решения, которые могут получать эту информацию без установки дополнительных программ. В качестве примера можно привести
инструменты сетевого сканирования, которые дистанционно проверяют на
серверах открытые порты, работающие сервисы и уязвимости, взаимодействуя
с существующими сетевыми протоколами и управляющими интерфейсами.
Некоторые решения проводят сканирование портов, проверяя серверы или хосты
в поисках открытых портов. Другие выполняют сканирование пакетов, что часто
требует перехвата и анализа сетевых пакетов для декодирования информации.
Эти инструменты также зависят от детализации обнаруженных данных, типов
хранения и информации, включаемой в отчет. Например, некоторые инструменты
могут предоставлять технологический стек более высокого уровня за пределами
сети, а также определять тип выполняемых приложений.
Сложность процесса инвентаризации зависит от рабочей нагрузки организации
и наличия у нее хорошо поддерживаемой системы учета. Этот этап обычно
занимает как минимум две недели, что позволяет собрать более целостную информацию о среде. Когда вся необходимая информация собрана, ее необходимо
проанализировать. Рассмотрим этап анализа более подробно.
Анализ информации
Анализ необходим, чтобы составить подробное преставление о текущем состоя
нии ИТ-инфраструктуры и принять обоснованные решения. Анализ помогает
определить, какие приложения и рабочие нагрузки подходят для миграции,
оценить их совместимость с облачными средами и подобрать оптимальные
облачные сервисы и архитектуру. Он также выявляет зависимости между приложениями и инфраструктурой, обеспечивая гладкий переход без прерывания
бизнес-операций. Кроме того, тщательный анализ упрощает прогнозирование
и устранение потенциальных рисков, оптимизацию ресурсов и планирование
затрат, тем самым обеспечивая экономически эффективную и успешную миграцию в облако.
128
Глава 3. Миграция на облачные платформы
Чтобы идентифицировать зависимости серверов и приложений, необходимо
проанализировать данные сетевых подключений, порты, информацию о системе
и процессах на хостах. В зависимости от доступных инструментов вы можете
получить наглядное представление всех обращений с сервера для идентификации его зависимостей или же выполнить запросы для получения списка всех
серверов, выполняющих конкретный процесс, использующих конкретный порт
или взаимодействующих с конкретным хостом.
Чтобы сгруппировать серверы и приложения для планирования миграции,
необходимо выявить закономерности в конфигурациях хостов. Часто в имена
серверных хостов включаются префиксы, обозначающие их связь с конкретной
рабочей нагрузкой, бизнес-подразделением, приложением или требованием.
В некоторых средах также используются теги и другие метаданные для связывания дополнительной информации с хостом.
y
y
Для оптимизации масштабирования целевой среды можно проанализировать
показатели производительности своих серверов и приложений.
y Если серверу выделены избыточные ресурсы, скорректируйте настройки
масштабирования. Этот процесс также можно оптимизировать, обрабатывая
данные реального использования серверов/приложений вместо заявленных
характеристик сервера.
y Если ресурсы сервера недостаточны, назначьте ему более высокий приоритет
для миграции в облако.
Полученную информацию можно объединить с доступностью иных ресурсов
и бизнес-требованиями для назначения приоритетов рабочей нагрузки облачной миграции. Это поможет определить, какое количество серверов включать
в каждый спринт облачной миграции.
После инвентаризации и анализа можно выбрать подходящую стратегию облачной миграции для приложений. Например, для менее сложных серверов
и приложений, работающих на поддерживаемой ОС, может подойти стратегия
lift-and-shift. Серверы или приложения, работающие на неподдерживаемой
ОС, могут потребовать дополнительного анализа для определения подходящей
стратегии.
На следующем этапе проекта миграции выполняется планирование облачной
миграции. Здесь информация, собранная при определении портфеля миграции
и анализе, используется для составления эффективного плана. Рассмотрим
планирование миграции более подробно.
Составление плана миграции
В проекте облачной миграции процессы инвентаризации, анализа и планирования тесно взаимосвязаны. Сначала полностью определяется портфель миграции,
а затем эти данные анализируются для создания плана миграции. В конце фазы
Этапы облачной миграции
129
y
y
y
анализа на основании анализа и сведений, полученных от владельцев бизнеса,
вы можете выполнить следующие действия для каждого сервера/приложения,
входящего в портфель облачной миграции:
y выбрать стратегию миграции в зависимости от стратегии перехода на облачные технологии, принятой в организации. Вероятно, выбор будет ограничен
фиксированными вариантами (одной из 7R стратегий);
y документировать бизнес-факторы для миграции ресурсов в облако, чтобы
определить необходимость и приоритеты;
назначить
приоритеты для миграции ресурсов в облако. В итоге все ре
y
сурсы, входящие в портфель облачной миграции, будут перенесены в облако, но приоритет определит срочность этой миграции. Ресурсы с более
высокими приоритетами можно переместить на первые позиции в очереди
миграции.
На этапе планирования информация, собранная в ходе определения и анализа,
используется для создания волн миграции. Волны представляют собой логические группировки ресурсов, которые могут быть последовательно развернуты
в рабочих средах, а также в средах тестирования/разработки, в процессе облачной миграции.
К концу этого этапа проекта миграции создается упорядоченная очередь приложений, которые могут быть перенесены в облако.
y
y
y
y
y
y
y
Кроме выбора стратегии миграции, этап планирования имеет следующие основные цели:
y определение критериев успеха миграции;
y определение правильного размера ресурсов в облаке;
y определение приоритета приложений при миграции в облако;
y выявление закономерностей миграции;
y создание подробного плана миграции, чеклиста и графика;
y формирование команд спринтов миграции;
y выбор инструментов для миграции.
Спринты и очереди задач — концепции методологий непрерывной доставки
Agile и Scrum.
В ходе подготовки к этапу планирования необходимо провести подробное определение и анализ всех ИТ-активов, входящих в портфель облачной миграции.
Планирование миграции включает выявление структуры учетных записей
в облаке и создание сетевой структуры приложения. Также очень важно понимать гибридные связи с облачной средой назначения. Гибридные связи помогут планировать приложения, зависящие от ресурсов, которые продолжают
выполняться локально.
130
Глава 3. Миграция на облачные платформы
Для определения порядка миграции приложений можно использовать три
высокоуровневых шага.
1. Оценить каждое приложение по нескольким измерениям (с точки зрения
как бизнеса, так и технологий), связанным с потенциальной миграцией, для
получения точных количественных оценок среды.
2. Выявить зависимости для каждого приложения и классифицировать их
(фиксированные, сильные связи, слабые связи), чтобы задавать любые требования к порядку миграции, основанные на зависимостях.
3. Определить правильную стратегию назначения приоритетов, чтобы присвоить относительные веса разным измерениям.
Если стратегия организации основана на минимизации риска, то больший вес
будет назначен идентификации приложений. Если стратегия основана на простоте миграции, то приложения, которые могут быть мигрированы методом
смены хоста, будут иметь более высокий приоритет, так как рехостинг проще,
чем другие стратегии. Результатом планирования должен быть упорядоченный
список приложений для графика облачной миграции.
Проектирование приложения
На этапе проектирования следует сосредоточиться на успешной миграции
приложений и проверке того, что архитектура приложения удовлетворяет
критериям успеха, определенным на этапе планирования. Также необходимо
следить, чтобы приложение осталось актуальным после перемещения в облако.
Например, если вы храните данные пользовательских сессий на локальном
сервере приложений (чтобы их можно было масштабировать горизонтально),
следует убедиться, что похожая архитектура будет реализована на облачной
платформе после миграции.
На этапе проектирования вы выявляете архитектурный разрыв и дораба
тываете архитектуру в соответствии с требованиями приложения. Если
в системе используются разные учетные записи, они могут иметь разные
уровни связей или зависимостей; например, учетная запись безопасности
может проверять, что все ресурсы соответствуют правилам безопасности,
принятым в компании.
y
y
y
y
y
Продумывая дизайн сети приложения, необходимо учитывать следующие
факторы:
y потоки сетевых пакетов, входящие в приложение;
y маршрутизация внешнего и внутреннего трафика;
y правила файрволов для защиты сети;
y изоляция приложения от интернета и внутренних приложений;
y общее соответствие сетевым стандартам и стандартам управления сетью;
Этапы облачной миграции
131
y
y
y сетевые журналы и аудит потока;
y разделение уровней риска приложения в зависимости от уровней взаимо-
y
y
y
y
y
действия с данными и пользователями;
y защита и предотвращение DDoS-атак;
y сетевые требования для рабочей и других сред;
y требования доступа для приложений на базе SaaS с совместной арендой;
y сетевые границы на уровне бизнес-подразделений в организации;
y выставление счетов и реализация модели общих сервисов между бизнесподразделениями.
В зависимости от потребностей в подключении можно рассмотреть гибридные
варианты с локальной системой.
Чтобы построить и обслуживать безопасную, надежную и экономически
эффективную архитектуру на облачной платформе, необходимо применять
лучшие практики. Перед миграцией проанализируйте, соответствует ли им
ваша облачная архитектура.
При миграции в облако можно спроектировать архитектуру приложения так,
чтобы пользоваться преимуществами глобальной облачной инфраструктуры,
приблизиться к конечному пользователю, снизить риски, улучшить защиту
и выполнить ограничения локализации данных. Системы, которые будут расти
со временем, должны строиться на основе масштабируемых архитектур, которые могут обеспечить рост пользователей, трафика или данных без ущерба для
производительности.
Часть компонентов архитектуры можно сделать компонентами без сохранения
состояния для приложений, которые должны поддерживать определенную
информацию состояния пользователя. Если какие-либо уровни архитектуры
должны обладать состоянием, для масштабирования упомянутых компонентов вы можете воспользоваться такими методами, как привязка сессий (session
affinity). Для приложений, обрабатывающих огромные объемы данных, применяется метод распределенной обработки.
Другой способ сокращения эксплуатационной сложности выполняемых приложений — использование бессерверной архитектуры. Эта разновидность архитектур сокращает затраты, поскольку с ней не нужно ни платить за недозагруженные
серверы, ни предоставлять избыточную инфраструктуру для реализации высокой
доступности. В главе 5 «Паттерны проектирования облачно-ориентированных
архитектур» вы больше узнаете о бессерверных архитектурах.
На диаграмме (рис. 3.5) показан пример проектирования миграции из локальной
среды в облако AWS. Локальная архитектура выглядит как показано на рисунке.
132
Глава 3. Миграция на облачные платформы
Пользователь
Интернет
Веб-сервер
Сервер приложения
Балансировщик
нагрузки
Сервер приложения
Веб-сервер
Сервер приложения
База данных
Резервная БД
Рис. 3.5. Перенос локальной архитектуры в облако
Представленная архитектура описывает конфигурацию веб-приложения с высокой доступностью, распределенную по нескольким уровням, каждый из которых
выполняет свои задачи по обработке пользовательских запросов. Пользователи
обращаются к приложению по интернету, а запросы равномерно перенаправляются балансировщиками нагрузки по кластеру веб-серверов.
Эти серверы предоставляют фронтенд-контент, а также могут выполнять начальную обработку запросов. Как следствие, более глубокая бизнес-логика
обслуживается отдельным уровнем серверов приложений, которые взаимодействуют с базой данных для получения и хранения данных. Для обеспечения
целостности данных поддерживается резервная база данных, готовая вступить
в работу, если у основной базы данных возникнут проблемы.
Многоуровневая архитектура с избыточностью на уровне веб-серверов и серверов приложений, а также стратегией обработки отказов для базы данных
направлена на обеспечение устойчивости при сбоях серверов и оптимальной
производительности даже при высоком трафике.
133
Этапы облачной миграции
Перейдем к проектированию архитектуры для облачной платформы AWS:
Облако AWS
Route 53
Amazon S3
Зона доступности 2
Зона доступности 1
Балансировщик нагрузки Elastic Load Balancer
VPC
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Amazon RDS
Реплика
экземпляра БД,
предназначенная
для чтения
Группа Auto Scaling
Веб-уровень
Группа Auto Scaling
Уровень приложения
Уровень базы данных
Кластер серверов Amazon EC2
Amazon
CloudFront
Кластер серверов Amazon EC2
Резервный
Реплика
экземпляра БД, экземпляр базы
данных
предназначенная
для чтения
Пользователи
Рис. 3.6. Перенос локальной архитектуры в облако
На приведенной диаграмме (рис. 3.6) показаны рехостинг веб-серверов и автомасштабирование для обеспечения эластичности, которая необходима, чтобы
справиться с выбросами нагрузки. Также в рамках стратегии облачной миграции были добавлены эластичные балансировщики нагрузки для распределения
входящего трафика по экземплярам веб-серверов.
Серверы приложений переносились методом рефакторинга, а платформа уровня
базы данных сменилась с традиционной на облачно-ориентированную Amazon
RDS (Amazon Relational Database Service). Вся архитектура распределяется
по нескольким зонам доступности, а база данных реплицируется в резервном
экземпляре во второй зоне для обеспечения высокой доступности.
y
y
y
y
В завершение этапа проектирования необходимо составить подробный документ
с описанием архитектуры приложения в облаке. Документ должен раскрывать
следующие темы.
y Миграция учетных записей пользователей: учетные записи пользователей,
которые будут перенесены в процессе миграции.
y Конфигурация сети: конфигурация сети, необходимая для приложения
в новой среде.
y Списки контроля доступа: полный список пользователей, групп и приложений, которым необходим доступ к перенесенным данным.
y Подробная информация о хостинге: где и как будет размещаться приложение после миграции.
134
Глава 3. Миграция на облачные платформы
y
y Требования к резервному копированию: стратегии резервного копирования
и специфические требования приложения.
y
y Потребности лицензирования: любые требования к лицензированию, свя-
y
y
y
занные с приложением.
y Протоколы мониторинга: системы и протоколы мониторинга, которые
должны действовать.
y Меры безопасности: меры безопасности и степень соответствия стандартам,
которые должно соблюдать приложение.
y Обслуживание и обновление: процедуры регулярного обслуживания и графики обновления.
Создайте дизайн-документ для каждого приложения. Выполните базовые тесты
функциональности на этапе проверки.
Выполнение миграции приложения в облако
Этап непосредственного выполнения миграции воплощает ваши планы в жизнь.
На этом этапе необходимо определить действия и конфигурации, так как вы
будете повторять их в волнах разработки/тестирования и эксплуатации. Прежде
чем выполнять миграцию, убедитесь, что у вас есть план миграции и вы сформировали команды спринтов, волны и графики миграции, создали приоритетную
очередь задач и оповестили стейкхолдеров о графике и сроках миграции, а также
их ролях и обязанностях.
Вы также должны убедиться, что среда назначения в облаке уже настроена
с фундаментальной архитектурой и основными сервисами. Для конкретных
приложений могут быть отдельные подготовительные этапы — например,
создание резервной копии или синхронизация перед миграцией, отключение
серверов или демонтаж дисков и устройств с сервера. Убедитесь, что все важнейшие компоненты подготовлены — например, сети и правила файрволов,
механизмы аутентификации и авторизации, учетные записи. Все должно быть
настроено как следует. Протестируйте приложения с инфраструктурой, чтобы
убедиться, что они имеют доступ к необходимым серверам, балансировщикам
нагрузки, базам данных, серверам аутентификации и т. д. Обратите внимание
на журналы приложений и мониторинг для измерения производительности
после миграции.
Убедитесь, что в ходе миграции установлено хорошее сетевое подключение с облачной средой. Качественная оценка объема данных, который должен быть передан в ходе миграции, также поможет оценить время, необходимое для миграции
данных в облако, с учетом таких факторов, как пропускная способность и сетевое
подключение. Также необходимо понимать, какие инструменты доступны для
выполнения миграции. С учетом количества имеющихся устройств на рынке
вам, возможно, придется сузить критерии выбора на основании требований
и других ограничений.
Этапы облачной миграции
135
Как вы уже знаете, рехостинг — зачастую самый быстрый способ миграции приложения в облако. Когда приложение работает на облачной платформе, его можно
дополнительно оптимизировать, чтобы пользоваться всеми преимуществами
облака. Выполняя миграцию приложений в облако методом lift-and-shift, можно
быстрее реализовать преимущества в части затрат и адаптивности.
В зависимости от выбранной стратегии обычно переносят либо весь сервер
вместе с приложением и инфраструктурой, в которой работает приложение,
либо только данные, принадлежащие приложению. Посмотрим, как проводится
миграция данных и серверов.
Миграция данных
y
y
Миграцией данных в облако называется процесс перемещения существующих
данных в новое облачное хранилище. Многие приложения требуют хранения
данных в процессе переноса в облако. Миграция хранилища обычно осуществляется одним из двух способов, хотя можно применять оба способа одновременно.
y Lift-and-shift. Может потребоваться до запуска новых приложений в облаке.
y Гибридная модель, ориентированная на облако. Реализуется для новых облачно-ориентированных проектов с унаследованными локальными данными. Унаследованные хранилища данных могут перемещаться на облачную
платформу позже.
Подход к миграции данных может меняться. Это зависит от таких факторов,
как объем данных, ограничения по структуре сети и пропускной способности,
уровень классификации данных (резервные данные, критические данные,
хранилища данных, архивные данные), уровень безопасности данных и время,
которое можно выделить для проведения миграции.
Представим, что у вас имеются обширные архивы данных или озера данных
и при этом низкая пропускная способность. В таком случае следует переместить данные из их текущего местоположения прямо в дата-центр облачного
провайдера методом lift-and-shift. Это можно сделать, используя выделенные
сетевые подключения для ускорения передачи по сети или физическим переносом данных на жестком диске.
Если хранилища данных можно постепенно переносить со временем или новые
данные собираются из многих необлачных источников, рассмотрите методы,
предоставляющие удобный интерфейс к сервису облачного хранилища. Эти
сервисы миграции могут использовать или дополнять существующие установки — например, программы резервного копирования/восстановления или сети
хранения данных (SAN, storage area network).
Для небольших баз данных одношаговая миграция является лучшим вариантом.
При этом требуется отключить приложение на небольшое время, от пары часов
до нескольких дней в зависимости от сложности рабочей нагрузки. Во время
простоя вся информация из базы данных извлекается и переносится в облачную
136
Глава 3. Миграция на облачные платформы
базу-приемник. После того как БД пройдет миграцию, ее можно будет сравнить
с исходной БД на предмет возможной потери данных. На этом миграция данных
может считаться завершенной.
В обратной ситуации, если система требует минимального времени простоя, для
баз данных любого размера чаще применяется двухэтапная миграция.
1. Информация извлекается из исходной базы данных.
2. Миграция данных выполняется во время работы базы данных. Вы можете
настроить механизм отслеживания измененных данных (CDC, Change Data
Capture), чтобы убедиться, что все данные прошли миграцию, а приложение
во время миграции продолжало работать.
В этом процессе простоя нет. После завершения миграции можно протестировать функциональность и производительность при подключении к внешним
приложениям или для любых других критериев.
Так как в это время исходная база данных все еще работает, изменения в ней
необходимо будет распространить или реплицировать, прежде чем отключить
окончательно. В этой точке вы планируете время простоя для базы данных
(обычно несколько часов) и синхронизируете исходную и целевую базы. После того как все изменения будут перенесены в целевую БД, проверьте данные,
чтобы убедиться в успешности миграции, и перенаправьте трафик приложения
в новую облачную базу.
Возможно, вам придется работать с критически важными базами данных, для которых недопустимы никакие простои. Проведение миграций с нулевым временем
простоя требует тщательного планирования и соответствующих инструментов
репликации данных. В таких сценариях необходимо использовать средства непрерывной репликации данных — такие, как AWS DataSync, Oracle GoldenGate
или NetApp SnapMirror. Важно отметить, что синхронная репликация может
повлиять на задержку исходной базы данных, так как она ожидает, пока данные
будут реплицированы повсюду, прежде чем отправлять ответ приложению.
Если простой базы данных длится лишь несколько минут, можно воспользоваться асинхронной репликацией. Миграция с нулевым временем простоя
предоставляет больше гибкости относительно момента переключения, так как
исходная и целевая базы данных всегда синхронизированы.
Миграция серверов
y
y
Существует несколько способов миграции сервера в облако.
y При методе клонирования ОС в исходной системе устанавливается агент,
который клонирует образ операционной системы. Снапшот создается в исходной системе и передается в целевую. Такой тип клонирования используется
для одноразовых миграций.
y При методе копирования ОС все файлы операционной системы копируются
с исходной машины и размещаются в облачном экземпляре. Чтобы метод
Этапы облачной миграции
137
y
y
y
y
y
копирования ОС работал эффективно, специалисты и/или инструменты,
выполняющие миграцию, должны хорошо знать нижележащую среду ОС.
y Метод репликации при аварийном восстановлении развертывает в исходной
системе агент, который будет реплицировать данные в целевой системе.
При этом репликация данных происходит на уровне файловой системы или
блоков. Некоторые решения непрерывно реплицируют данные по целевым
томам.
y Копирование дисковых томов полностью осуществляется методом копирования диска. После копирования всего объема диска его можно загружать
в облако по томам, которые затем присоединять к облачному экземпляру.
y В случае виртуальных машин (VM) можно воспользоваться безагентскими
методами для экспортирования/импортирования VM в облако. Локальный
образ VM копируется методом копирования VM. Если локальные серверы
работают как VM (например, VMware или OpenStack), можно скопировать
образ VM и импортировать его в облако как образ машины. Главное преимущество этого метода — наличие резервных образов сервера, которые могут
запускаться повторно.
y Методом копирования пользовательских данных копируются только пользовательские данные приложения. После экспорта данных с исходного сервера
можно выбрать одну из трех стратегий миграции — повторная покупка, смена
платформы или рефакторинг. Метод копирования пользовательских данных
подходит только для тех, кто знает внутреннее устройство приложения.
С другой стороны, так как он только извлекает пользовательские данные,
этот метод является ОС-независимым.
y Вы можете провести контейнеризацию приложения, а затем заново развернуть его в облаке. Метод контейнеризации копирует как двоичные файлы
приложений, так и пользовательские данные. После копирования двоичных
и пользовательских данных приложение может выполняться в контейнерной исполнительной среде, размещенной в облаке. Так как нижележащая
платформа меняется, это можно рассматривать как пример стратегии платформенной миграции.
На рынке представлены несколько средств миграции, которые помогут провести миграцию данных и/или серверов в облако. Каждый крупный провайдер
публичных облачных платформ предоставляет собственный инструмент миграции: при этом можно применять другие популярные инструменты миграции —
CloudEndure, NetApp, Dynatrace, Carbonite, OpenText и т. д. Некоторые инструменты используют стратегию аварийного восстановления для миграции, а часть
инструментов аварийного восстановления также поддерживает непрерывную
репликацию для удобства миграций работающих приложений. Некоторые специализируются на перемещении серверов методом lift-and-shift, миграциях баз
данных между платформами или преобразованиях схем баз данных. Инструмент
должен поддерживать бизнес-процессы, с которыми вам удобно работать и для
управления которыми у вас есть квалифицированные специалисты.
138
Глава 3. Миграция на облачные платформы
Интеграция, проверка и переключение
Миграция, интеграция и проверка неразрывно связаны, так как во время выполнения интеграций с приложением в облаке необходимо проводить непрерывную проверку.
Проверка
Для начала следует проверить облачную функциональность, чтобы убедиться,
что приложение выполняется с верной конфигурацией сети (в нужной геолокации) и с желательным уровнем трафика. После завершения проверки базовой облачной функциональности экземпляры можно по мере необходимости запускать
или останавливать. Также желательно проверить, что серверная конфигурация
(объем памяти, процессор, жесткий диск) соответствует ожидаемой.
Для выполнения этих проверок необходимо владеть информацией о приложении
и его функциональности. Когда первичная проверка будет завершена, можно
переходить к интеграционным тестам.
Интеграция
В ходе интеграционных тестов проверяется интеграция с внешними зависимостями и приложениями — например, что приложение успешно подключается
к Active Directory, сервисам CRM, серверам обновлений или управления конфигурацией и общим сервисам. Представим, что приложение должно взаимодействовать с сервером Active Directory, сервером управления конфигурацией
или ресурсами общих сервисов, внешними для приложения. Приложению
также может потребоваться интеграция с внешними приложениями, которые
принадлежат вашим клиентам или внешним источникам (например, поставщик
может получать информацию от API приложения после размещения заказа на
покупку).
После завершения процесса интеграции необходимо провести юнит-тесты,
дымовые (smoke) тесты и приемочные тесты (UAT, User Acceptance Test). Результаты этих тестов помогут получить одобрение от владельцев приложения
и бизнеса.
На последнем шаге этапа интеграции и проверки выполняется официальное
согласование с владельцами приложения и бизнеса, что позволит перейти к переключению приложения с локальной среды на облачную.
Переключение
Следующий этап облачной миграции — процесс переключения (cutover). На
этом шаге выполняются необходимые действия для перенаправления трафика
приложения из исходной локальной среды в целевую облачную среду. В зависимости от типа данных или типа миграции сервера (одношаговая, двухшаговая
или с нулевым временем простоя) последовательность действий в процессе
Этапы облачной миграции
139
y
y
y
y
y
y
переключения может изменяться. Вот некоторые факторы, которые необходимо
учитывать при определении стратегии переключения:
y приемлемое время простоя для приложения;
y частота обновлений данных;
y особенности обращения к данным (например, данные только для чтения
или статические);
y требования, специфические для приложения (например, синхронизация
с базой данных, резервное копирование, разрешение имен DNS);
y бизнес-ограничения (например, день или время, в которое может произойти
переключение, критичность данных);
y изменение правил управления и согласования.
Живая (live) миграция — самая популярная модель для миграции рабочей нагрузки, критически важной для бизнеса. Рассмотрим ее подробнее.
Переключение при живой миграции
При этом способе данные непрерывно реплицируются в место назначения,
и бˆольшая часть функционального проверочного и интеграционного тестирования
выполняется в месте назначения во время работы приложения. На рис. 3.7 представлена стратегия переключения для живой миграции с нулевым временем простоя.
На диаграмме изображена гибридная облачная архитектура, используемая
с сине-зеленым развертыванием для переключения в режиме живой миграции.
80 %
трафика
Облако AWS
Северная Вирджиния (США)
20 %
трафика
Route 53
Ирландия (Европа)
Веб-серверы
Кластер серверов Amazon EC2
Парк веб-серверов
Серверы приложений
Кластер серверов Amazon EC2
Парк серверов приложений
Amazon RDS
Локальный узел
Репликация данных
База данных
Рис. 3.7. Переключение при живой миграции с использованием
сине-зеленого развертывания
140
Глава 3. Миграция на облачные платформы
Принцип сине-зеленого развертывания заключается в следующем: в «синей»
среде работает существующая рабочая среда с живым трафиком. Параллельно
предоставляется «зеленая» среда, почти идентичная синей, но использующая
новую версию кода. О сине-зеленом развертывании подробнее пойдет речь
в главе 11 «DevOps и фреймворк архитектуры решений».
Вот как это работает в контексте диаграммы.
1. Текущая конфигурация (синяя среда): локальный дата-центр, находящийся
в Европе (Ирландия), состоит из веб-серверов, серверов приложений и базы
данных. Он обрабатывает определенный процент пользовательского трафика
(20 %, как показано на диаграмме).
2. Целевая конфигурация (зеленая среда): облачная конфигурация AWS
в регионе Северная Вирджиния (США) — новая среда, которая готовится
к обслуживанию всего трафика. Она включает кластер экземпляров Amazon
EC2 для парка веб-серверов и другой кластер для парка серверов приложений.
В качестве базы данных используется Amazon RDS.
3. Маршрутизация и распределение трафика: DNS-сервис Amazon Route
53 используется для маршрутизации пользовательского трафика между
локальной и облачной средами AWS. Изначально он настроен на отправку
большей части трафика (80 %) облачной среде AWS, тогда как оставшийся
трафик все еще передается локальному дата-центру.
4. Репликация данных: репликация данных непрерывно выполняется из
локальной базы данных в Amazon RDS из облака AWS, чтобы обеспечить
целостность данных и актуальность информации в облачной среде.
5. Переключение при живой миграции: на этапе переключения при сине-
зеленом развертывании новая (зеленая) среда в AWS становится полностью
работоспособна и обслуживает бˆольшую часть трафика.
6. После тщательного тестирования и подтверждения того, что новая среда работает стабильно и с ожидаемой производительностью, Route 53 со временем
перемещает весь трафик из локальной (синей) среды в облачную (зеленую).
7. На этом этапе локальная среда остается в резерве. Если в облачной конфигурации AWS возникнут критические проблемы, трафик может быть возвращен
на локальные серверы для обеспечения непрерывности сервиса.
8. Завершение: после того как переключение будет успешно завершено и облачная среда AWS начнет обрабатывать весь трафик, локальная инфраструктура может быть выведена из эксплуатации или перепрофилирована
для других целей.
Такой подход сводит к минимуму простои и риски, поскольку новая среда
проходит полное тестирование с живым трафиком до того, как прежняя среда
будет выведена из эксплуатации. Он также обеспечивает простой откат, если
при переключении возникнут проблемы.
Этапы облачной миграции
141
На начальной стадии приложение продолжает работать как локально, так
и в облаке, с распределением трафика между двумя этими сторонами. Можно
постепенно повышать долю трафика в облаке, пока весь он не будет передан
новому приложению, что обеспечит переключение без простоя.
Другие часто используемые стратегии переключения подразумевают некоторое
время простоя. Для их реализации необходимо спланировать время простоя приложения, приостановить трафик, перевести приложение в офлайн и провести
последнюю синхронизацию с применением CDC.
После завершающей синхронизации стоит выполнить быстрый дымовой тест,
чтобы убедиться, что все критические функции работают как нужно. В этой точке
можно перенаправить трафик от исходной среды к приложению, работающему
в облаке, таким образом завершая переключение.
Очень важно синхронизировать данные в ходе миграции, так как они
непрерывно изменяются во время работы приложения. Для выполнения
одноразовой миграции данных CDC используются такие средства миграции,
как AWS Database Migration Service (DMS) и Oracle GoldenGate.
Эксплуатация облачного приложения
Этап эксплуатации помогает запускать и использовать приложения в облаке на
уровне, согласованном с бизнес-стейкхолдерами.
Многие организации уже имеют готовые руководства по эксплуатации, определенные для их локальных сред. Это помогает понять, какие изменения в процессе и какой объем обучения необходимы, чтобы поддерживать цели перехода
на облачные технологии.
y
y
y
y
y
y
y
y
y
Ниже перечислены операции, которые необходимо проводить в облаке:
y установка обновлений на сервере;
y ведение журналов сервисов и приложений;
y облачный мониторинг;
y управление событиями;
y облачные операции безопасности;
y управление конфигурацией;
y управление облачными ресурсами;
y управление изменениями;
y непрерывность деятельности с аварийным восстановлением и высокой доступностью.
Для большинства из этих операций приняты такие стандарты, как ITIL
(Information Technology Infrastructure Library) и ITSM (Information Technology
Service Management). ITSM упорядочивает и описывает действия и процессы
142
Глава 3. Миграция на облачные платформы
планирования, создания, управления и поддержки ИТ-сервисов, тогда как
ITIL применяет лучшие практики для реализации ITSM. Необходимо модернизировать принятые в организации практики ITSM, чтобы пользоваться преимуществами адаптивности, безопасности и экономической эффективности,
предоставляемыми облаком.
По завершении миграции в облако ваша работа еще не закончена. Для полного
раскрытия потенциала облака необходима непрерывная оптимизация. Рассмотрим эту тему более подробно.
Оптимизация приложений в облаке
y
y
y
y
y
Оптимизация — важнейшее условие работы в облаке. По сути, это непрерывное улучшение. В этом разделе вы узнаете о различных областях оптимизации.
В книге разным факторам оптимизации посвящены целые главы. Ниже перечислены основные области оптимизации.
y Производительность: оптимизируйте производительность всего набора
ресурсов (экземпляров, хранилищ, баз данных, доступного пространства
и времени). Вы больше узнаете об архитектурных факторах производительности в главе 6 «Факторы производительности».
y Безопасность: непрерывно анализируйте и совершенствуйте политики
и процессы безопасности в организации, чтобы защитить данные и ресурсы
в облаке. Архитектурные факторы безопасности более подробно рассматриваются в главе 7 «Факторы безопасности»
y Надежность: оптимизируйте приложения для повышения надежности; это
помогает достичь высокой доступности и определенных пороговых значений
времени простоя для приложений. Тем самым упрощается восстановление
после отказов, обработка возрастающей нагрузки и устранение сбоев с течением времени. Вы больше узнаете об архитектурных факторах надежности
в главе 8 «Факторы надежности архитектуры».
y Операционное совершенство (operational excellence): оптимизируйте операционную эффективность и возможность запуска/мониторинга систем в целях
обеспечения ценности для бизнеса и непрерывного улучшения поддержки
процессов и процедур. В главе 9 «Операционное совершенство» вы больше
узнаете об операционных факторах архитектуры.
y Затраты: оптимизируйте экономическую эффективность приложения или
группы приложений с учетом колебаний потребностей в ресурсах. Вы больше
узнаете об экономических факторах архитектуры в главе 10 «Оптимизация
затрат».
Вы должны понимать, какие именно ресурсы в настоящее время развертываются
в вашей облачной среде, и представлять цену каждого из этих ресурсов для оптимизации затрат. Вы можете организовать упреждающее отслеживание затрат
в облаке, используя подробные отчеты тарификации и включение оповещений
тарификации.
Создание гибридной облачной архитектуры
143
Необходимо поддерживать и масштабировать инфраструктуру и меньше платить
по мере выведения большего количества ресурсов. Другой способ оптимизации
затрат основан на проектировании архитектуры с учетом эластичности. Убедитесь, что вы верно определили размеры своих ресурсов, применяете авто
масштабирование и регулируете потребление в зависимости от цены и потребности. Например, для приложения может быть выгоднее использовать много
небольших экземпляров, чем меньшее количество более крупных.
Некоторые архитектурные модификации помогут улучшить производительность приложения. Один из вариантов повышения производительности вебсерверов — кэширование для ускорения обращений к веб-страницам. Можно
написать приложение, которое позволяет кэшировать графику, JavaScript и даже
целые страницы, чтобы улучшить пользовательский опыт.
Можно спроектировать n-уровневые и сервис-ориентированные архитектуры
для независимого масштабирования каждого уровня и модуля, что также способствует оптимизации производительности. В главе 4 «Паттерны проектирования
архитектур решений» вы узнаете об этом подробнее.
Возможно, придется сохранить локальную рабочую нагрузку в процессе облачной
миграции. Причиной может быть многоэтапность или невозможность провести
миграцию в облако из-за сложности приложения либо проблем лицензирования. В таких сценариях необходимо построить гибридное решение, в котором
локальная рабочая нагрузка может взаимодействовать с облачной и легко
обмениваться с ней информацией. В следующем разделе создание гибридных
облачных архитектур рассматривается более подробно.
Создание гибридной облачной архитектуры
Ценность облачных технологий растет, и многие крупные компании перемещают
свою рабочую нагрузку в облако. Тем не менее часто оказывается невозможно
полностью перейти в облако за один день — для большинства клиентов этот
процесс занимает некоторое время. Таким клиентам необходима гибридная
облачная модель, в которой часть приложения, поддерживаемая в локальной
среде, должна взаимодействовать с облачным модулем.
y
При гибридном развертывании необходимо обеспечить связь между ресурсами, выполняемыми в локальной и облачной средах. В самом популярном
варианте гибридное развертывание соединяет облачную и существующую
локальную инфраструктуры в облако для расширения и роста инфраструктуры организации с сохранением связи облачных ресурсов с внутренней
системой. Вот некоторые распространенные причины создания гибридных
облачных архитектур.
y Во время рефакторинга и развертывания в облаке по сине-зеленой модели
необходимо сохранить работоспособность старых приложений в локальной
среде.
144
Глава 3. Миграция на облачные платформы
y
y Старое приложение (например, на мейнфрейме) может не иметь совмести-
y
y
y
y
мых облачных вариантов и должно продолжать работать в локальной среде.
Лучше всего найти время на рефакторинг технологического стека.
y Часть приложения должна оставаться в локальной среде из-за требований
комплаенса.
y Для ускорения миграции необходимо оставить базу данных в локальной
среде и переместить сервер приложения в облако.
y Необходимо более точно контролировать часть приложения.
y Необходимо извлекать данные в облако из локальной среды для аналитики.
Провайдеры публичных облачных сервисов предоставляют механизм интеграции
существующей инфраструктуры клиента в облако, чтобы клиенты могли легко
использовать его как естественное расширение текущих вложений в инфраструктуру. Функциональность гибридных архитектур позволяет клиентам делать все:
от интеграции сетей, безопасности и контроля доступа до автоматизированных
процессов миграции рабочей нагрузки и централизованного управления облаком
с помощью локальных инструментов.
Как видно из рис. 3.8, с помощью AWS Direct Connect можно установить
скоростной канал связи между дата-центром и облаком AWS для реализации
гибридного развертывания с низкой задержкой.
Выделенное сетевое соединение
по частным линиям
Облако AWS
VPC
802.1qVLAN
Увеличенная пропускная
способность и улучшенная
задержка
Подсеть 1
Зона доступности 1
AWS
WAN
клиента
Клиент
Клиент
VGM
AWS Direct Connect
Подсеть 1
Зона доступности 2
Удаленный сервер
Ячейка AWS Direct Connect
Удаленная сеть клиента
Рис. 3.8. Гибридная облачная архитектура (связь локальной среды с облачной)
На диаграмме VPC — Amazon Virtual Private Cloud, VLAN — виртуальная локальная
сеть (Virtual Local Area Network), VGM — виртуальный частный шлюз (Virtual
Private Gateway), а 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 к трафику.
Чтобы эффективно сбалансировать риски и преимущества гибридной облачной
модели, необходимо провести комплексную оценку.
y
y
y
y
y
y
y
y
Гибридная облачная модель имеет следующие преимущества.
y Гибкость и контроль: гибридные облачные решения предоставляют возможность использования масштабируемости публичных облачных платформ
с сохранением критических рабочих нагрузок в локальных средах для улучшения контроля и производительности.
y Масштабируемость: компании могут масштабировать свои ИТ-ресурсы по
требованию, чтобы те могли справляться с пиковыми нагрузками без значительных капитальных вложений в физическую инфраструктуру.
y Улучшенная устойчивость: за счет распределения ресурсов по нескольким
средам гибридная облачная стратегия может улучшить общую устойчивость
системы и обеспечить непрерывность ведения бизнеса.
y Инновации и эксперименты: гибридная облачная модель позволяет организациям тестировать новые облачные технологии и сервисы без нарушения
работоспособности основных бизнес-приложений, которые остаются в локальных средах.
Впрочем, наряду с преимуществами есть и риски.
y Сложность: гибридная облачная среда комплексная по своей природе, она
требует сложных функций оркестрации и возможностей сети для гладкого
управления рабочими нагрузками на разных платформах.
y Безопасность: расширение поверхности потенциальных атак (из-за соединения публичных и частных облаков) требует жестких мер безопасности
и постоянной бдительности.
y Проблемы комплаенса: распределение данных и приложений по разным
облачным средам усложняет соблюдение стандартов.
y Управление затратами: без тщательного планирования и мониторинга расходы на эксплуатацию гибридного решения могут быстро превысить ожидания
из-за недозагрузки ресурсов или теневых ИТ-ресурсов.
146
Глава 3. Миграция на облачные платформы
Принимая решение о реализации гибридной облачной стратегии, следует сравнить эти риски с потенциальными преимуществами, учитывая специфические
потребности организации, необходимую функциональность и стратегические
цели.
С расширением предложения на рынке облачных решений от известных провайдеров организации могут выбрать мультиоблачный подход. Мультиоблачные
стратегии рассматриваются в следующем разделе.
Мультиоблачные решения
Еще до появления облачных технологий организации пользовались продуктами
разных компаний, чтобы иметь доступ к лучшим предложениям в своем классе
и избежать привязки к конкретному поставщику. С появлением на рынке новых
игроков в области публичных облачных платформ у организаций возник интерес
к созданию мультиоблачных решений. Мультиоблачное решение использует
два и более провайдеров публичных облачных платформ для обслуживания
инфраструктурных и технологических потребностей организации. Мульти
облачная стратегия может сочетать предложения основных провайдеров: AWS,
GCP, Microsoft Azure, Oracle Cloud, IBM и др. Организации могут распределять
свою рабочую нагрузку между облаками в зависимости от географической доступности, технических возможностей и затрат. Они также могут объединять
мультиоблачные решения с локальными.
y
y
y
y
Ниже перечислены некоторые важные преимущества мультиоблачных стратегий.
y Гибкость в отношении провайдера: в мультиоблачном решении можно выбирать между провайдерами без ущерба для стоимости, гибкости и адаптивности. При нарушении соглашения об уровне обслуживания (SLA, ServiceLevel Agreement) можно переключиться на другого облачного провайдера.
y Аварийное восстановление: планирование аварийного восстановления
в том же регионе, поскольку при сбое у одного из провайдеров вы можете
положиться на других. У каждого провайдера облачной платформы есть свои
сильные стороны, и можно выбрать лучшие сервисы, доступные в облаке.
Хотя мультиоблачный подход предоставляет конкурентные преимущества
организациям, у него есть и недостатки.
y Один из самых очевидных — навыки сотрудников. При создании стратегии
хостинга рабочей нагрузки придется найти специалистов по нескольким
облачным технологиям. Более того, команды должны глубоко изучить каждый облачный технологический стек. Подумайте о найме консультанта или
передаче управления облаком на аутсорс интеграторам глобальных систем,
у которых есть соответствующие специалисты.
y Другая серьезная проблема — координация доступности данных, безопасности и производительности по нескольким облакам. Хотя каждый провайдер
облачных технологий предоставляет встроенные средства безопасности,
Реализация CloudOps
147
кросс-региональные приложения и облачно-ориентированные инструменты
для производительности, ответственность за облако в целом несет организация. Вам придется реализовать последовательное управление данными
между облаками, получение данных из одного облака и передачу их в другое,
а также обеспечить стабильную производительность.
Таким образом, мультиоблачный подход имеет как преимущества, так и недостатки, которые необходимо учитывать при выборе стратегии.
Начав путешествие в мир облачных технологий, вы сможете создавать облачно-ориентированные приложения. Построение облачно-ориентированных
архитектур рассматривается в следующем разделе.
Реализация CloudOps
Модель облачных операций CloudOps представляет собой набор правил и рекомендаций, устанавливаемых, отслеживаемых и изменяемых организациями
для управления затратами, повышения эффективности и устранения рисков
облачной инфраструктуры, безопасности и эксплуатации. Эта операционная
модель служит руководством для того, чтобы навыки и действия сотрудников,
процессы и технологии соответствовали облачным задачам, включая безопасность облачных рабочих нагрузок, управление бюджетом и комплаенс.
y
y
y
y
y
Важные преимущества модели CloudOps:
y раскрытие потенциала скорости и адаптивности: организации могут использовать преимущества гибкости и быстроты отклика, присущие облачным сервисам, ускоряя переход на облачные технологии и модернизацию
приложений как часть цифровой трансформации;
y применение автоматизации для повышения эффективности: автоматизация
уменьшает количество ошибок и вмешательств за счет упрощения рутинных
задач, высвобождая ценные ресурсы и время;
y последовательное управление в масштабе организации: в разных средах
поддерживаются единые облачные механизмы управления, что обеспечивает
стандартизацию и комплаенс в пределах организации;
y эффективное применение навыков сотрудников: CloudOps позволяет специалистам сосредоточиться на достижении бизнес-результатов вместо ручного
выполнения монотонных, однообразных задач;
y сокращение затрат: используя средства автоматизации и управления,
организации могут избежать непредвиденных расходов и оптимизировать
облачные затраты.
Чтобы применять все лучшие облачные практики, компаниям, переходящим
в облако, исключительно важен эффективный менеджмент. Облачные сервисы управления обеспечивают более высокую скорость внедрения инноваций
и контроль затрат, комплаенса и безопасности.
148
Глава 3. Миграция на облачные платформы
Автоматизация играет ключевую роль в разработке эффективных моделей облачных операций: облачные ресурсы можно создавать, модифицировать и удалять
автоматически. Концепция облачных сервисов по требованию обеспечивает
гибкость, но на практике многие организации все еще полагаются на ручные
процессы в части выделения, тестирования, определения необходимости и вывода из эксплуатации облачных ресурсов. Ручные рабочие процессы приводят
к повышению трудоемкости, потенциальным ошибкам и росту затрат.
y
y
y
Облачная автоматизация может потребовать некоторых усилий на начальном
этапе, но ее преимущества становятся очевидны, когда даже сложные задачи
начинают выполняться быстро и за несколько кликов. Кроме заметного сокращения объема ручной работы, облачная автоматизация предоставляет и другие
преимущества, в том числе:
y повышение безопасности и устойчивости: автоматизация способствует
повышению безопасности за счет сокращения человеческих ошибок и обес
печения правильной реализации мер безопасности — например, настройки
учетных данных для новых добавляемых сред разработки. Кроме того, возможно автоматизированное восстановление при возникновении проблем
безопасности, а это повышает устойчивость и предотвращает простои;
y упрощение процессов резервного копирования: автоматизация резервного
копирования обеспечивает непрерывность ведения бизнеса, улучшает доверие клиентов при аварийном восстановлении и минимизирует потери для
бизнеса. Автоматизированное резервное копирование устраняет зависимость
от сотрудников, которые должны запускать этот процесс, что снижает риск
потери данных;
y расширение возможностей управления: автоматизация обеспечивает всесторонний мониторинг операций между средами, расширяя возможности
управления за счет отслеживания серверов, баз данных и контроля доступа.
Облачные провайдеры предоставляют широкий спектр сервисов и инструментов для поддержки современных предприятий в реализации модели 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 .
Итоги
В этой главе мы разобрали фундаментальные принципы архитектуры решений в публичном облаке. Вы познакомились с облачно-ориентированными
и гибридными архитектурами и получили полное представление об облачных
технологиях и их преимуществах.
В начале главы мы сравнили публичные, частные и гибридные облака. Сравнение
помогает понять разные модели облачного развертывания и соответствующие
им сценарии использования.
Затем концепция публичных облачных платформ была определена более подробно через ее архитектуру. Мы также представили некоторых популярных
провайдеров облачных сервисов.
Далее мы перешли к подробному изучению облачно-ориентированной архитектуры. Вы получили представление о преимуществах перехода на такую архитектуру, например улучшенной масштабируемости, гибкости и экономической
эффективности.
Разобрав основы публичных облачных платформ, мы перешли к обсуждению
стратегий облачной миграции.
Мы подробно исследовали разные подходы к миграции, включая метод liftand-shift, рехостинг, смену платформы, релокацию, рефакторинг, повторное
приобретение, сохранение и удаление. Были приведены рекомендации по выбору наиболее подходящей стратегии облачной миграции в зависимости от
бизнес-требований.
В следующих разделах были описаны основные этапы облачной миграции,
начиная с определения рабочей нагрузки и анализа. Вы узнали, как составить подробный план миграции и спроектировать приложения для гладкой
миграции в облако. Также мы рассмотрели важные вопросы миграции приложения, включая миграцию данных, миграцию серверов, интеграцию, проверку и переключение. Мы представили методы оптимизации приложений
в облаке, обеспечивающие оптимальную производительность и экономическую
эффективность.
Дополнительные источники
151
Так как организации часто имеют дело со сложными инфраструктурами, мы
поговорили о том, как создать гибридную облачную архитектуру и использовать
мультиоблачные решения, чтобы пользоваться всеми преимуществами разных
облачных провайдеров.
Глава завершилась обсуждением того, как проектировать облачно-ориентированные архитектуры. Особое внимание было уделено принципам CloudOps,
помогающим в практической реализации облачной рабочей нагрузки.
В следующей главе рассматриваются паттерны проектирования архитектур
и основные архитектуры — многоуровневые, сервис-ориентированные, бессерверные и микросервисные.
Дополнительные источники
y
y
y
y
y
y
За дополнительной информацией об основных провайдерах облачных платформ
обращайтесь по следующим ссылкам.
y 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/;
y Google Cloud Platform (https://cloud.google.com):
GCP Cloud Architecture Framework: https://cloud.google.com/architecture/
framework;
Microsoft
Azure (https://azure.microsoft.com):
y
Azure Well-Architected: https://azure.microsoft.com/en-us/solutions/cloudenablement/well-architected#reliability;
y Oracle Cloud Infrastructure (OCI): https://www.oracle.com/cloud/;
y Alibaba Cloud: https://us.alibabacloud.com;
y IBM Cloud: https://www.ibm.com/cloud.
Почти каждый облачный провайдер предоставляет новым пользователям возможности для освоения своих продуктов. Вы можете зарегистрироваться со
своим адресом электронной почты и опробовать их предложения, прежде чем
остановить выбор на одном из них.
ГЛАВА 4
ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
АРХИТЕКТУР РЕШЕНИЙ
Вы когда-нибудь задумывались над тем, как большие компании проектируют
масштабируемые системы? Прежде чем браться за разработку приложений,
архитекторы решений прорабатывают и сравнивают разные варианты, чтобы
спроектировать архитектуру, соответствующую бизнес-потребностям.
Существует много способов проектирования. Архитектор решений должен
выбрать наиболее подходящий в зависимости от пользовательских требований и архитектурных ограничений в отношении затрат, производительности,
масштабируемости и доступности. В этой главе будут представлены различные
паттерны архитектуры решений, основные (эталонные) архитектуры и их применение в реальных сценариях.
В предыдущих главах вы узнали о принципах проектирования архитектуры
решений. Материал этой главы интересен и важен, так как вы сможете применить свои знания к разным паттернам проектирования архитектур. В этой
главе мы разберем некоторые популярные паттерны архитектур решений:
многоуровневые, управляемые событиями, микросервисные, слабосвязанные,
сервис-ориентированные и RESTful-архитектуры.
Вы узнаете о преимуществах разных архитектурных стилей и рассмотрите
примеры, демонстрирующие их применение. Кроме того, вы научитесь видеть
некоторые антипаттерны проектирования наряду со следующими паттернами.
y
y
y
y
y
y
y
y
y
y
В этой главе мы рассмотрим следующие вопросы.
y Построение n-уровневой архитектуры.
y Создание мультитенантной архитектуры на базе SaaS.
y Понимание сервис-ориентированной архитектуры.
y RESTful-архитектура веб-сервисов.
y Построение архитектур на базе кэша.
y Паттерн MVC (Model-View-Controller, модель — представление — контроллер).
y Построение архитектур, управляемых предметной областью (DDD).
y Паттерн «Предохранитель» (Circuit Breaker).
y Паттерн «Переборка» (Bulkhead).
y Паттерн «Плавающий IP» (floating IP).
Паттерны проектирования архитектур решений 153
y
y
y
y
Развертывание приложения в контейнере.
Работа с базами данных в архитектуре приложений.
Чистая архитектура.
Уход от антипаттернов в архитектурах решений.
К концу главы вы будете знать, как оптимизировать архитектуру решения
и применять лучшие практики. Можно сказать, что эта глава станет смысловым
центром, самой важной частью вашего обучения.
y
y
y
y
Построение n-уровневой архитектуры
В n-уровневой архитектуре (также называемой многоуровневой архитектурой)
применяются принципы и атрибуты слабосвязанных архитектур, а также масштабируемости и эластичности. Функции продукта делятся на уровни (представления, бизнеса, баз данных, сервисов), чтобы каждый уровень можно было
реализовать и масштабировать независимо от других (рис. 4.1).
N-уровневая архитектура упрощает внедрение новых технологий и разработку. Она также обеспечивает гибкость добавления новой функциональности
на каждом уровне без последствий для функциональности других уровней.
В контексте безопасности каждый уровень может поддерживаться безопасным
и изолированным от других, так что, если один уровень будет скомпрометирован, это не отразится на других. Многоуровневая архитектура также облегчает диагностику и управление приложениями, так как позволяет быстро
определить источник проблем и ту часть приложения, в которой необходимо
провести диагностику.
Облако AWS
Route 53
Зона доступности 1
VPC
Amazon S3
Зона доступности 2
Балансировщик нагрузки Elastic Load Balancer
DynamoDB NoSQL Store
Кластер серверов Amazon EC2
Веб-уровень
Группа Auto
Scaling
Кластер серверов Amazon EC2
Группа Auto Scaling
Уровень приложения
Реплика
Уровень базы данных
Amazon RDS экземпляра БД,
предназначенная
для чтения
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Реплика
Резервный
экземпляра БД, экземпляр базы
предназначенная
данных
для чтения
Рис. 4.1. Трехуровневая архитектура веб-сайта
Amazon
CloudFront
154
Глава 4. Паттерны проектирования архитектур решений
Самая распространенная многоуровневая архитектура — трехуровневая,
и о ней стоит поговорить подробнее. На рис. 4.1 представлен пример архитектуры AWS, которая обеспечивает взаимодействие с веб-приложением
из браузера и выполнение необходимых действий — например, купить в интернет-магазине футболку или прочитать блог и оставить комментарий.
y
y
y
Представленная архитектура состоит из трех уровней.
y Веб-уровень: часть приложения, обращенная к пользователю. Конечные
пользователи взаимодействуют с веб-уровнем для сбора или предоставления
информации.
y Уровень приложения: состоит в основном из бизнес-логики и действует на
основании информации, полученной с веб-уровня.
y Уровень базы данных: на этом уровне хранятся все виды пользовательских
данных и данных приложения.
Рассмотрим эти уровни более подробно.
Веб-уровень
Также называется уровнем представления (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) арендатора каждой организации.
1
Создание мультитенантной архитектуры на базе SaaS
157
Т1-БД
Т2-БД
Изоляция уровня базы данных
2
3
пользователь
ID арендатора
Арендатор-1 (Организация 1)
Уровень
представления
Уровень
приложений
Уровень
доступа
к данным
ID арендатора
1
Т1-Таблица
Т2-Таблица
Изоляция уровня таблиц
Таблица
2
3
пользователь
Арендатор-2 (Организация 2)
РК-Т1
ряд 1
РК-Т2
ряд 2
Изоляция уровня строк
Рис. 4.2. Мультитенантная архитектура SaaS
y
y
y
На приведенной архитектурной диаграмме показано, что уровень представления
предоставляет пользовательский интерфейс, а уровень приложения используется
для хранения бизнес-логики. На уровне доступа к данным у каждого арендатора
изоляция базы данных обеспечивается одним из следующих способов.
y Изоляция на уровне базы данных: в этой модели каждый арендатор связывается со своим ID базы данных. Когда арендаторы запрашивают данные
из пользовательского интерфейса, каждый перенаправляется к своей базе
данных. Эта модель необходима, если клиенты не могут пользоваться общей
базой данных из соображений комплаенса и безопасности.
y Изоляция на уровне таблиц: этот уровень изоляции достигается выделением отдельной таблицы каждому арендатору. В этой модели таблица должна
однозначно связываться с арендатором, для чего ей назначается префикс с ID
пользователя. Когда арендатор запрашивает данные из пользовательского
интерфейса, запрос перенаправляется к таблице с его уникальным ID.
Изоляция
на уровне строк: на этом уровне изоляции все арендаторы соy
вместно используют одну таблицу базы данных. В таблице присутствует
дополнительный столбец, в котором хранится уникальный ID арендатора
для каждой строки данных. Когда отдельный арендатор хочет обратиться
к своим данным из пользовательского интерфейса, уровень доступа к данным
формулирует запрос к общей таблице, включающий ID арендатора. Каждый
арендатор получает строку, которая относится только к их пользователям.
Если подписка на сервис нужна многим пользователям, важно найти предложение, подходящее по соотношению цены и качества. Выбирая между покупкой или
созданием, необходимо проводить сравнение затрат с учетом общей стоимости
владения. Для большинства организаций создание программных продуктов
158
Глава 4. Паттерны проектирования архитектур решений
не является основной специализацией. Модель SaaS набирает популярность еще
и потому, что она позволяет организациям сосредоточиться на своей профильной
деятельности и предоставить решение ИТ-вопросов техническим экспертам.
Для корпоративных клиентов необходимо провести тщательный анализ, чтобы
понять, подойдет ли им решение SaaS в зависимости от их специфических
требований к функциональности. Дело в том, что возможности настройки
модели SaaS часто ограниченны.
Выбор механизма изоляции определяется факторами, зависящими от требований комплаенса и безопасности в организации, затратами и условиями,
относящимися к заключению контрактов арендаторами.
Сервис-ориентированная архитектура (SOA, Service-Oriented Architecture) —
популярный метод проектирования и построения приложений, особенно если
требования организаций уникальные и специфические. SOA более подробно
рассматривается в следующем разделе.
Сервис-ориентированная архитектура
В паттернах SOA разные компоненты приложений взаимодействуют по сети
с использованием коммуникационного протокола. Каждый сервис предоставляет сквозную функциональность (например, получение истории заказов).
Архитектура SOA широко применяется в больших системах для интеграции
бизнес-процессов — например, выделения платежного сервиса из основного
приложения и размещения его в отдельном решении.
Коротко говоря, архитектуры SOA берут монолитные приложения и выделяют
некоторые операции в отдельные сервисы, работающие независимо. Целью SOA
становится ослабление связей с сервисами приложения. Иногда SOA включает
отделение сервисов друг от друга и выделение ресурсов в дополнительные экземпляры этого сервиса. Например, в то время как некоторые компании предпочитают хранить свои данные в одной БД, разбитой по таблицам, архитектор
SOA обратится к возможности модуляризации приложения по функциям
в разные базы данных. Это позволяет масштабировать пропускную способность
и управлять ею на основании индивидуальных потребностей таблиц каждой
базы данных.
SOA предоставляет ряд преимуществ — например, параллелизацию разработки,
развертывания и эксплуатации. Эта архитектура ослабляет связи между сервисами, чтобы оптимизировать и масштабировать каждый сервис по отдельности.
С другой стороны, она также требует более надежного управления, чтобы работа,
выполняемая командами разных сервисов, соответствовала одному стандарту.
С применением SOA решение может стать достаточно сложным, и затраты
на поддержку этой сложности заметно возрастут, так что следует тщательно
Сервис-ориентированная архитектура
159
выбирать инструменты и автоматизировать мониторинг, развертывание и масштабирование сервисов.
Есть несколько вариантов реализации SOA.
Когда-то протокол SOAP (Simple Object Access Protocol) был самым популярным
протоколом передачи сообщений, но он слишком тяжел, так как обмен данными
осуществляется полностью в XML. Архитектура REST (Representational State
Transfer) становится более популярной, так как разработчикам нужно строить
более легкие мобильные и веб-приложения. На момент написания книги архитектура SOAP считается устаревшей, так что в этом издании мы сосредоточимся
на архитектуре REST.
RESTful-архитектура
RESTful (REST-совместимый) веб-сервис обеспечивает более высокую производительность благодаря своей облегченной архитектуре. Он допускает разные
форматы передачи сообщений (JSON, простой текст, HTML, XML), в отличие
от архитектуры SOAP, которая поддерживает только XML. REST — архитектурный стиль, определяющий стандарт проектирования приложений со слабой
связанностью, использующий протокол HTTP для передачи данных.
JSON (JavaScript Object Notation) — более доступный формат для обмена данными в архитектуре REST, упрощенный и не привязанный к конкретному языку.
В нем используются простые пары «ключ — значение», которые обеспечивают
его совместимость со структурами данных, определяемыми в большинстве
языков программирования.
y
Веб-сервисы RESTful формируют архитектурный фреймворк с особыми правилами проектирования веб-сервисов. Они нацелены на обеспечение совместимости между разными компьютерными системами, соединенными по интернету.
С веб-сервисами RESTful системы могут взаимодействовать через обращение
к текстовым данным и их изменение, используя согласованный и заранее
определенный набор операций, не зависящих от прошлых взаимодействий
или состояний. Рассмотрим некоторые фундаментальные принципы RESTfulархитектуры веб-сервисов с их наглядным представлением на примере сайта
интернет-магазина.
y Отсутствие состояния (stateless): каждый запрос от клиента к серверу
должен содержать всю информацию, необходимую серверу для понимания
и обработки запроса. Каждый запрос, выдаваемый клиентом, включает всю
необходимую информацию для выполнения, и хранить на сервере какуюлибо информацию, относящуюся к сессии, не нужно: все управление такой
информацией осуществляется полностью на стороне клиента. В примере
с интернет-магазином каждый запрос от клиента (например, просмотр товара
или добавление его в корзину) должен содержать всю информацию, необходимую для обработки. Если пользователь захочет просмотреть содержимое
своей корзины, запрос должен включать идентификатор этой корзины или
160
Глава 4. Паттерны проектирования архитектур решений
y
y
y
другую информацию, чтобы сервер мог найти запрошенные данные и вернуть
их в ответе.
y Архитектура «клиент — сервер»: в этой архитектуре выделяются две разные
части, клиент и сервер, взаимодействующие друг с другом по сети. Клиент
отвечает за управление пользовательским интерфейсом и взаимодействие
с пользователем, а сервер — за бэкенд и обработку данных. Они могут
развиваться по отдельности, не влияя друг на друга. Клиент (браузер или
приложение) управляет взаимодействиями с пользователем (например,
выбором товаров), а сервер обеспечивает выборку данных, управление корзиной и оформление заказов. Взаимодействие между ними осуществляется
посредством запросов и ответов HTTP.
y Однородный интерфейс: REST использует однородный интерфейс, упрощающий архитектуру и ослабляющий связи в ней. В RESTful API для взаимодействий используется набор стандартных методов HTTP, соответствующих
операциям CRUD (Create, Read, Update, Delete), то есть создание, чтение,
обновление, удаление:
GET: метод используется для получения данных с сервера. Например,
когда пользователь хочет просмотреть список товаров на сайте example.
com, его браузер отправляет серверу запрос GET. URL-адрес может иметь
вид https://example.com/api/products, а сервер отвечает списком товаров
в структурированном формате (например, JSON или XML);
POST: метод используется для создания нового ресурса на сервере. Представим, что пользователь хочет добавить новый товар в свою корзину на сайте
example.com. Он может заполнить форму с описанием товара и щелкнуть
кнопку Add to Cart (Добавить в корзину). Это действие инициирует запрос
POST к URL https://example.com/api/cart, при этом подробная информация
о товаре включается в тело запроса. Затем сервер обрабатывает данные
и добавляет новый товар в корзину пользователя;
PUT : метод используется для обновления существующего ресурса на
сервере. Если пользователь хочет обновить количество единиц товара
в своей корзине, запрос PUT отправляется по специальному URL вида
https://example.com/api/cart/{productId}. Тело запроса включает обновленное
количество, а сервер обновляет соответствующую позицию в корзине
пользователя;
DELETE: метод используется для удаления ресурса с сервера. Например,
если пользователь хочет удалить товар из своей корзины, его браузер отправляет запрос DELETE к URL вида https://example.com/api/cart/{productId}.
Сервер удаляет указанный товар из корзины.
y Ограничиваясь этими стандартными методами, API предоставляют разработчикам согласованный механизм взаимодействия с веб-сервисами. Это
позволяет разработчикам выполнять основные операции с ресурсами, при
этом им не нужно понимать подробности реализации.
Создание сайта интернет-магазина на базе RESTful-архитектуры
161
y
y Ресурсы: в REST все считается ресурсом, и конкретные URL могут обращать-
y
y
y
ся к любым ресурсам. Ресурсы являются ключевыми абстракциями в REST,
и ресурс может представлять один объект или набор объектов. Такие ресурсы,
как товары, пользователи, заказы и позиции корзины, идентифицируются
URL-адресами. Например, для обращения к конкретному товару может использоваться URL вида www.amazon.com/products/{product_id}.
y Представление ресурсов: ресурсы могут иметь разные представления:
JSON, XML, HTML и т. д. Клиенты взаимодействуют с ресурсами, получая
их представления и выполняя операции с этими представлениями. Когда
клиент хранит представление ресурса, у него достаточно информации для
модификации ресурса на сервере. Один и тот же ресурс товара может поразному отображаться в веб-браузере и в мобильном приложении.
y Многоуровневая система: архитектура позволяет вводить промежуточные
уровни (например, балансировщиков нагрузки или кэширования) без влия
ния на то, как клиент взаимодействует с сервером. Каждый уровень может
предоставлять конкретную функциональность, что улучшает масштабирование и обслуживаемость системы. Сайт интернет-магазина может содержать
разные уровни: балансировщиков нагрузки, кэширования, аутентификации
и т. д. Клиенту знать об этих уровнях необязательно. Запрос на просмотр
товара может пройти через уровень кэширования для ускорения ответа,
причем клиент об этом ничего не будет знать.
y Код по требованию: серверы могут предоставлять клиенту исполняемый
код для выполнения в контексте клиента. Это позволяет переместить часть
логики приложения на сторону клиента. Сайт интернет-магазина может отправить клиентскому браузеру код JavaScript для выполнения определенной
функциональности (например, проверки на стороне клиента или улучшения
интерактивности при просмотре страницы клиентом).
Архитектурный стиль RESTful использует стандартные методы HTTP. Соблюдение этих принципов позволяет веб-сервисам RESTful быть простыми,
масштабируемыми и удобными в обслуживании. Многие современные веб-API
разрабатывались с соблюдением принципов RESTful и использованием стандартных соглашений для выполнения операций CRUD с ресурсами.
Давайте рассмотрим пример RESTful-архитектуры.
Создание сайта интернет-магазина
на базе RESTful-архитектуры
Некоторые интернет-магазины (например, www.amazon.com) имеют пользователей со всего мира и огромный каталог с миллионами товаров. С каждым
товаром хранятся его изображения, а также отзывы и видеоролики. Поддержка
такого обширного каталога для глобальной пользовательской базы — весьма
непростая задача.
162
Глава 4. Паттерны проектирования архитектур решений
Представленная ниже архитектура AWS (рис. 4.3) следует принципам RESTful.
Сервисы работают максимально независимо друг от друга.
Облако AWS
Amazon S3 для журналов,
данных Clickstream
и изображений товаров
VPC
Сервис
рекомендаций
товаров
Каталог
и кэш сессии
КЭШ
Route 53
Поисковая
система на
базе Amazon
Elasticsearch
КЭШ
Elasticache
Amazon CloudFront
Запросы на покупку и платежи
через SSL
Сервис
приложения
интернетмагазина
Сервис
оформления
заказа
DynamoDB для каталога
товаров, профилей
пользователей и хранилища
пользовательских операций
Рис. 4.3. RESTful-архитектура интернет-магазина
На этой диаграмме можно отметить несколько особенностей.
y
y Когда пользователь вводит адрес сайта в браузере, его запрос направляется
y
y
y
серверу DNS для загрузки сайта. Запросы DNS маршрутизируются сервисом
Amazon Route 53 к серверу, на котором размещаются веб-приложения.
y Пользовательская база является глобальной. Далее пользователи обычно
просматривают товары, так как на сайте представлен обширный каталог
со статическими изображениями и видеороликами. Сеть распространения
контента (в данном случае Amazon CloudFront) кэширует и поставляет статические ресурсы пользователям.
y Содержимое каталога (в частности, статические изображения товаров
и видеоролики), а также другие данные приложения (например, файлы
журналов) хранятся в Amazon S3.
y Пользователи могут просматривать сайт с нескольких устройств; например,
добавить товары в корзину с мобильного устройства, а оплатить покупку
с настольного компьютера. Для поддержки пользовательских сессий требуется долгосрочное хранилище сессионных данных — такое, как DynamoDB.
DynamoDB представляет собой базу данных NoSQL, для которой не нужна
фиксированная схема, поэтому данный вариант отлично подходит для каталогов товаров и атрибутов.
Создание сайта интернет-магазина на базе RESTful-архитектуры
163
y
y Amazon ElastiCache используется как уровень кэширования товаров, чтобы
y
y
y
сократить количество операций чтения из базы данных и записи в нее, обес
печить высокую производительность и сократить задержку.
y Удобные средства поиска чрезвычайно важны для продаж и успеха бизнеса.
Amazon CloudSearch помогает построить масштабируемую функциональность поиска за счет загрузки каталога товаров из DynamoDB. Также можно
воспользоваться Amazon Kendra для создания поисковой системы с поддержкой ИИ.
y Рекомендации, основанные на истории просмотра и покупок, могут стимулировать пользователя к приобретению дополнительных товаров. Отдельный
рекомендательный сервис может потреблять данные журналов, хранящиеся
в Amazon S3, и предоставлять пользователю рекомендации для возможных
покупок.
y Приложение интернет-магазина также может иметь множественные уровни
и компоненты, требующие частоты развертывания. AWS Elastic Beanstalk
осуществляет автоматическое выделение инфраструктуры, развертывание
приложения, обрабатывает нагрузку за счет применения автомасштабирования и проводит мониторинг приложения.
В этом разделе вы познакомились с архитектурой RESTful. В следующем разделе рассматривается важная тема — архитектура на базе кэша.
Построение архитектуры на базе кэша
Кэшированием называется временное хранение данных или файлов в промежуточном хранилище, расположенном между источником запроса и долгосрочным хранилищем. Эта практика направлена на ускорение будущих запросов и сокращение нагрузки на канал связи. Кэширование повышает скорость
работы приложений и снижает затраты. Оно позволяет повторно использовать
ранее загруженные данные. Для повышения производительности приложения
кэширование может применяться на разных уровнях архитектуры: веб-уровне,
уровне приложения, уровне данных и сетевом уровне.
В общем случае для поддержки кэширования приложений используются оперативная память (RAM) и системы кэширования в памяти. Если кэширование
связано с локальным сервером, кэш не сохранит данные в случае его сбоя.
Многие приложения работают в распределенной среде, так что лучше создать
выделенный уровень кэширования, не зависящий от жизненного цикла приложения. При применении к приложению горизонтального масштабирования
все серверы должны иметь возможность обращаться к центральному уровню
кэширования для достижения наилучшей производительности.
На рис. 4.4 изображен механизм кэширования на разных уровнях архитектуры
решения.
Уровни архитектуры решения
164
Глава 4. Паттерны проектирования архитектур решений
Сторона клиента
(мобильного
и десктопного)
Быстрое получение контента веб-сайтов
с использованием заголовков кэширования HTTP и браузеров
Интернет
(система доменных
имен — DNS)
Быстрое преобразование домена в IP-адрес
с помощью DNS-сервера
Веб-контент
(веб-уровень)
Быстрое получение контента с веб-серверов и управление веб-сессиями
на стороне сервера
Приложение
(уровень
приложения)
Улучшение производительности приложения и ускорение обращения
к данным с использованием хранилищ данных «ключ-значение»
и локальных кэшей
База данных
(уровень БД)
Сокращение задержки, связанной с запросами к базе данных,
при помощи буферов баз данных и хранилищ
данных «ключ-значение»
Рис. 4.4. Кэширование на разных уровнях архитектуры
y
Как показано на диаграмме, на каждом уровне архитектуры используется свой
механизм кэширования.
y Кэширование на стороне клиента: применяется с мобильными устройствами
и десктопными компьютерами. Этот механизм кэширует ранее просмотренный веб-контент, чтобы быстрее реагировать на последующие запросы. Каждый браузер имеет собственный механизм кэширования. Кэширование HTTP
ускоряет приложение за счет кэширования контента в локальном браузере.
Заголовок HTTP cache-control описывает политики кэширования браузера для клиентских запросов и ответов сервера. Эти политики определяют,
где должен кэшироваться контент и сколько времени он должен храниться;
Создание сайта интернет-магазина на базе RESTful-архитектуры
165
y
y
y
y
этот параметр называется «сроком жизни», или TTL (Time To Live). Файлы cookie — еще один метод хранения информации на машине клиента для
ускорения ответа браузеру.
Интернет-кэш
DNS: когда пользователь вводит адрес сайта в интернете,
y
публичный сервер DNS проводит сопоставление IP-адреса. Кэширование
этой информации снижает время загрузки сайтов. Информация DNS может
кэшироваться на локальном сервере или браузере после первого запроса,
и все последующие запросы к этому сайту будут ускоряться.
y Кэширование веб-контента: многие запросы включают загрузку веб-контента:
графики, видео, страниц HTML. Кэширование этих ресурсов поблизости
от местоположения пользователя может значительно ускорить ответ при
загрузке страницы. Оно также снижает время чтения данных и загрузки
сервера. CDN (сеть доставки контента) представляет собой сеть пограничных локаций (edge locations), в которых может кэшироваться статический
контент (графика, видео). Это особенно полезно при чтении тяжеловесных
приложений: игр, блогов, страниц каталогов товаров и т. д. Пользовательская
сессия содержит большой объем информации, связанной с предпочтениями
пользователя и его текущим состоянием. Чтобы улучшить взаимодействие
с пользователями, данные сессии хранятся в специальном хранилище пар
«ключ — значение» для ускорения ответов.
y Кэширование уровня приложений: на уровне приложения кэширование
может применяться для хранения результата сложных повторяющихся
запросов, чтобы избежать многократного выполнения бизнес-логики
и о бращений к базе данных. В целом этот подход улучшает произво
дительность приложения, сокращая нагрузку на базу данных и инфраструктуру.
y Кэширование базы данных: производительность приложения сильно
зависит от скорости и пропускной способности, обеспечиваемых базой
данных. Кэширование базы данных значительно повышает ее пропускную
способность и снижает задержку выборки данных. Кэш базы данных может
устанавливаться перед любой реляционной или нереляционной БД. Некоторые поставщики БД реализуют интегрированное кэширование, тогда как
приложения обеспечивают локальное кэширование.
Redis и Memcached — самые популярные системы кэширования. Хотя
Memcached работает быстрее (система подходит для низкоструктурированных
данных и организует их хранение в формате «ключ-значение»), Redis — более
устойчивая система кэширования, способная работать со сложными структурами
данных, необходимых для приложения; тема более подробно рассматривается
в разделе «Memcached и Redis» этой главы.
Рассмотрим некоторые распространенные паттерны кэширования.
166
Глава 4. Паттерны проектирования архитектур решений
Паттерн Cashe distribution (Распределенное
кэширование) в трехуровневой веб-архитектуре
Традиционная архитектура веб-хостинга следует популярной трехуровневой
модели веб-приложений, в которой архитектура делится на уровни представления, приложения и хранения данных.
Как показано на архитектурной диаграмме AWS на рис. 4.5, кэширование применяется на веб-уровне, уровне приложения и уровне баз данных.
Облако AWS
Route 53
Зона доступности 1
Amazon S3
Зона доступности 2
Балансировщик нагрузки Elastic Load Balancer
VPC
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Amazon
ElastiCache
Amazon RDS
Веб-уровень
Группа Auto
Scaling
Группа Auto Scaling
Уровень приложения
Уровень базы данных
Кластер серверов Amazon EC2
Amazon
CloudFront
Кластер серверов Amazon EC2
Реплика
Резервный
экземпляра БД, экземпляр базы
предназначенная
данных
для чтения
Пользователи
Рис. 4.5. Архитектура паттерна «Распределенное кэширование»
y
y
y
y
Паттерны кэширования необходимо использовать с целью свести к минимуму
количество обращений к базе данных. Чтобы повысить качество взаимодействия
с пользователями, можно написать приложение, в котором кэшируются изображения, JavaScript и даже целые страницы. На приведенной выше диаграмме
кэширование реализуется между разными уровнями архитектуры.
y Amazon Route 53 используется для кэширования соответствий между DNS
и IP, упрощая управление доменами.
y Amazon S3 служит хранилищем статического контента, включая графику
высокого разрешения и видеоролики.
y Amazon CloudFront предоставляет кэширование на границе сети для контента
с высоким трафиком, используя заголовки cache-control для определения
частоты обновления по источнику.
y Amazon DynamoDB используется для сессионных хранилищ, что позволяет
веб-приложениям управлять пользовательскими сессиями посредством
кэширования.
Создание сайта интернет-магазина на базе RESTful-архитектуры
167
y
y Механизм балансировки нагрузки Elastic Load Balancing равномерно расy
пределяет трафик между группами Auto Scaling веб-серверов.
Amazon
ElastiCache предоставляет сервисы кэширования приложениям,
y
фактически сокращая нагрузку на уровень базы данных.
Обычно кэшируется статический контент, но в некоторых сценариях кэширование динамического или уникального контента может улучшить производительность приложения. Решение зависит от конкретных паттернов использования
и потребностей.
Рассмотрим один из таких паттернов.
Паттерн Rename distribution (Распределение
с переименованием)
При работе с CDN (например, Amazon CloudFront) часто используемые данные хранятся в пограничных локациях рядом с пользователем для повышения
производительности. Обычно в CDN устанавливается срок жизни (TTL) для
данных, это означает, что пограничная локация не будет обращаться к серверу
с запросом обновленных данных, пока TTL не истечет. Напомним, что TTL
определяет время хранения объекта в системе кэширования, прежде чем он
будет удален или обновлен. Возможны сценарии, в которых требуется обновить
кэшированный контент CDN немедленно — например, если нужно исправить
ошибочное описание товара.
В такой ситуации нельзя ожидать истечения TTL. Паттерн «Распределение
с переименованием» позволяет обновить кэш сразу после публикации новых
изменений, чтобы пользователь мог немедленно получить обновленную информацию. На рис. 4.6 показано применение этого паттерна с AWS.
Как видно из диаграммы, использование паттерна «Распределение с переименованием» совместно с паттерном «Распределение кэширования» помогает решить
проблему с обновлением. При использовании этого паттерна вместо того, чтобы
переписать файл на сервере-источнике и ожидать истечения TTL в Cloudfront,
сервер отправляет обновленный файл с новым именем, после чего обновляет
веб-страницу новым URL. Когда пользователь запрашивает исходный контент,
CloudFront приходится загружать его из источника (вместо предоставления
устаревшего файла, уже находящегося в кэше).
Впрочем, старый файл можно инвалидировать сразу же, но это будет дорого
стоить, поэтому лучше поместить новую версию файла в CDN, чтобы начать
ее использовать немедленно. Чтобы загружался новый файл, придется снова
обновить URL в приложении, что добавляет затрат по сравнению с вариантом
инвалидации кэша. Решение следует выбирать в зависимости от бизнес-требований и бюджета.
168
Глава 4. Паттерны проектирования архитектур решений
3. CloudFront получает обновленную
версию с сервера-источника
Amazon CloudFront
2. Страница распространяется
с обновленным URL
Облако AWS
Ячейка Amazon S3
1. Новые данные размещаются
с новым именем файла
Веб-приложение
Рис. 4.6. Архитектура паттерна «Распределение с переименованием»
Если пользовательская база имеет широкое географическое распределение
и вы не хотите использовать CDN, можно воспользоваться кэширующим
прокси-сервером. Этот вариант более подробно рассматривается в следующем
разделе.
Паттерн Cache proxy (Кэширующий прокси-сервер)
Добавление уровня кэширования может значительно повысить производительность приложения. В паттерне «Кэширующий прокси-сервер» статический
или динамический контент кэшируется выше уровня сервера веб-приложения.
На рис. 4.7 показано, что уровень кэширования помещается перед кластером
веб-приложения.
На этой диаграмме для обеспечения высокопроизводительной поставки данных
содержимое кэша поставляется кэширующим сервером.
y
y
y
Некоторые преимущества паттерна «Кэширующий прокси-сервер»:
y он обеспечивает поставку контента с использованием кэша, не требуя изменений на уровне веб-сервера или сервера приложения;
y он снижает нагрузку на генерирование динамического контента;
y кэш можно организовать на уровне браузера: кэшировать заголовки HTTP,
URL, cookie и т. д. Также можно кэшировать информацию на уровне кэша,
если вы не хотите хранить ее на уровне браузера.
При использовании паттерна «Кэширующий прокси-сервер» приходится поддерживать несколько копий кэша, чтобы избежать появления единой точки
отказа. В некоторых случаях статический контент должен поставляться как
с сервера, так и из CDN. Эта гибридная ситуация рассматривается в следующем разделе.
Создание сайта интернет-магазина на базе RESTful-архитектуры
169
Пользователь
Облако AWS
Балансировщик нагрузки
Elastic Load Balancer
Подсеть
КЭШ
Веб-приложение
КЭШ
Веб-приложение
Веб-приложение
Рис. 4.7. Архитектура паттерна «Кэширующий прокси-сервер»
Паттерн Rewrite proxy
(Заменяющий прокси-сервер)
Иногда бывает нужно изменить ссылки для обращений к статическому контенту
веб-сайта (например, графике и видео) без изменения существующих систем. Для
этого можно выделить прокси-сервер с использованием паттерна «Заменяющий
прокси-сервер». Чтобы перевести обращения к статическому контенту на другое
хранилище (например, сервис контента или интернет-хранилище), установите
прокси-сервер перед парком веб-серверов.
На рис. 4.8 прокси-сервер установлен перед уровнем приложения, что позволяет
изменить местоположение поставки контента без изменения самого приложения.
Как показано на диаграмме, прокси-сервер, реализующий паттерн, размещается
перед работающей системой. Для создания прокси-сервера можно воспользоваться такими продуктами, как Apache или NGINX.
Ниже представлена последовательность действий для построения паттерна
«Заменяющий прокси-сервер» с использованием AWS, как в примере.
1. Разместите в экземпляре EC2 работающий прокси-сервер, который может
перезаписывать контент между балансировщиком нагрузки и сервисом
хранения (например, Amazon S3), в котором хранится статический контент.
170
Глава 4. Паттерны проектирования архитектур решений
2. Добавьте правила прокси-сервера для перезаписи URL в контенте. Эти
правила помогут ELB (Elastic Load Balancing) обратиться к новому местонахождению, как на рис. 4.8, где правило прокси-сервера перенаправляется
с https://cdn/test.jpg на /test.jpg. ELB — предоставляемый AWS сервис, который автоматически распределяет входящий трафик приложения между
несколькими целями (например, серверами Amazon EC2, контейнерами
и IP-адресами).
3. Примените автомасштабирование к прокси-серверам, настроив минимальное
и максимальное количество прокси-серверов в соответствии с нагрузкой
приложения.
В этом разделе вы узнали, как реализовать кэширование для распределения
статического контента в сети. Однако в улучшении производительности приложения важную роль играет кэширование на уровне приложения. Посмотрим,
как паттерн кэширования приложения применяется для управления производительностью доставки динамических пользовательских данных.
Пользователь
Облако AWS
Балансировщик нагрузки
Elastic Load Balancer
<img src="https://cdn/test.jpg"/>
Подсеть
Проксисервер
Проксисервер
<img src="/test.jpg"/>
Amazon CloudFront
S3 Bucket
Веб-приложение
Веб-приложение
Рис. 4.8. Архитектура паттерна «Заменяющий прокси-сервер»
Создание сайта интернет-магазина на базе RESTful-архитектуры
171
Паттерн App caching
(Кэширование на уровне приложения)
Для реализации кэширования в приложениях необходимо добавить уровень
кэширования между серверами приложений и базой данных. Паттерн «Кэширование на уровне приложения» позволяет сократить нагрузку на базу данных,
так как самые частые запросы будут обслуживаться с уровня кэширования.
Этот паттерн повышает общую производительность приложений и баз данных.
Как показано на рис. 4.9, уровень кэширования добавляется между уровнем
приложения и уровнем базы данных в AWS.
AWS Cloud
Балансировщик нагрузки Elastic Load Balancer
VPC
Группа Auto Scaling
Парк серверов приложения
Уровень
кэширования
Amazon RDS
Сервер приложения запрашивает данные у механизма
кэширования, и если данные
отсутствуют в кэше, они загружаются из базы данных
Механизм кэширования
загружает данные в кэш
и обслуживает запрос из
кэшированных данных
Уровень кэширования перед базой
данных сокращает количество обращений к ней, что повышает общую
производительность приложения
Рис. 4.9. Архитектура паттерна «Кэширование на уровне приложения»
При обращениях к данным может использоваться либо отложенное кэширование (lazy caching), либо кэширование со сквозной записью (write-through).
В первом случае механизм кэширования проверяет, находятся ли данные в кэше,
и если нет — загружает их из базы данных и сохраняет в кэше для обслуживания
будущих запросов. Отложенное кэширование также называется кэшированием
на стороне (cache aside). При кэшировании со сквозной записью данные записываются в кэш и хранилище данных одновременно. Если данные в кэше будут
потеряны, их можно снова получить из базы данных.
Выбирайте отложенное кэширование, если вы используете приложение с интенсивным чтением, а кэширование со сквозной записью — при операциях, требующих немедленной согласованности данных. Например, отложенное кэширование
может использоваться для каталога товаров на сайте интернет-магазина, где
172
Глава 4. Паттерны проектирования архитектур решений
подробные описания товаров часто читаются, но обновляются намного реже.
Когда пользователь обращается к описанию товара, отсутствующему в кэше, оно
загружается из базы данных и сохраняется в кэше для последующих обращений,
что сокращает нагрузку на базу данных. Кэширование со сквозной записью
может использоваться для раздела отзывов пользователей на сайте интернетмагазина, где написанные пользователями отзывы мгновенно отображаются на
странице товара. Когда пользователь отправляет свой отзыв, он записывается
в кэш и базу данных одновременно, гарантируя, что все последующие запросы
чтения получат самые актуальные данные.
В следующем разделе рассматриваются популярные системы кэширования
Redis и Memcached.
Memcached и Redis
Memcached и Redis — две популярные системы кэширования, используемые
при разработке приложений. Redis часто применяется для более сложных
требований — например, создания таблицы лидеров игры. Со своей стороны,
Memcached более производителен и позволяет справляться с более серьезными
нагрузками приложений.
У каждой системы кэширования имеются сильные и слабые стороны. Рассмотрим наиболее существенные различия между ними — это поможет вам принять
решение о том, какую из них использовать (табл. 4.1).
Таблица 4.1. Сравнение Memcached и Redis
Memcached
Redis
Поддерживает многопоточность
Однопоточное выполнение
Может использовать дополнительные
ядра процессора для ускорения выполнения
Не может использовать многоядерный
процессор, из-за чего работает относительно медленно
Поддерживает данные в стиле «ключ —
значение»
Поддерживает сложные и продвинутые
структуры данных
Долгосрочное хранение данных не поддерживается; данные, хранящиеся в памяти кэша, теряются в случае сбоя
Возможно долгосрочное хранение данных, для чего используются встроенные
реплики для чтения с механизмом обработки отказов
Прост в обслуживании
Обслуживание усложняется необходимостью поддержки кластера
Хорошо подходит для кэширования неструктурированных строковых данных:
неструктурированных страниц HTML,
сериализованной разметки JSON и т. д.
Хорошо подойдет для создания кэша
таблицы лидеров игры, приложения для
голосования в реальном времени и т. д.
Архитектура MVC (Model-View-Controller)
173
Если вам нужно решить, какую систему использовать, выберите сценарий,
который оправдает использование Redis или Memcached. Memcached проще
и требует меньших затрат на обслуживание; обычно эту систему выбирают,
когда кэшу не нужна расширенная функциональность, которую предоставляет
Redis. С другой стороны, Redis лучше подойдет, если требуется долгосрочное
хранение данных, работа со сложными типами данных или любые другие из
перечисленных возможностей.
При реализации кэширования важно учитывать актуальность кэшируемых данных. При высокой частоте попаданий в кэш (cashe hit) запрашиваемые данные
часто находятся в кэше. Сокращение числа прямых обращений снижает нагрузку
на базу данных и повышает общую производительность приложения. Промах
кэша (cashe miss) происходит, когда запрашиваемые данные отсутствуют в кэше,
что повышает нагрузку на базу данных. Объем кэша ограничен, так что следует
установить TTL и вытеснять старые данные из кэша в соответствии с потребностями приложения.
Как было показано в этом разделе, применение кэша имеет ряд преимуществ,
включая повышение производительности, обеспечение прогнозируемой производительности и сокращение затрат при работе с базой данных.
В следующем разделе представлена архитектура на базе приложения, демонстрирующая принцип слабой связанности и работы с ограничениями, — MVC.
Архитектура MVC (Model-View-Controller)
y
MVC — один из самых популярных паттернов проектирования, встречающихся
при разработке приложений. В этой архитектуре приложение разделяется на три
взаимосвязанных компонента: модель (Model), представление (View) и контроллер (Controller). Такое деление улучшает модульность разработки, упрощает
тестирование и обслуживание. Рассмотрим эти компоненты по отдельности.
y Модель: представляет внутреннее состояние приложения вместе с правилами,
логикой и данными, которые управляют состоянием. Модель не зависит от
представления или контроллера; это означает, что изменения в пользовательском интерфейсе или бизнес-логике не влияют на работу с данными. Таким
образом обеспечивается согласованность данных между разными частями
приложения. К обязанностям модели относятся:
управление данными: модель содержит всю логику, относящуюся к данным. Независимо от того, получены ли данные из базы данных или API,
модель обработает их;
реализация бизнес-правил: модель реализует бизнес-логику (например,
вычисления или преобразования данных);
уведомление об изменениях: модель уведомляет связанные с ней представления и контроллеры об изменениях данных, чтобы те могли обновиться соответствующим образом.
174
Глава 4. Паттерны проектирования архитектур решений
y
y Представление: визуальное представление данных модели. Оно точно опреде-
y
y
y
y
y
ляет, как данные приложения отображаются для пользователя. Представление
автоматически обновляется при изменении нижележащих данных модели;
это гарантирует, что пользователь всегда видит самые актуальные данные.
На базе одних данных модели можно создать несколько представлений
в разных форматах (таблицы, диаграммы, детализированные представления).
К обязанностям представления относятся:
отображение данных: получает данные из модели и представляет их
в понятном формате;
обслуживание пользовательского интерфейса (UI): обрабатывает всю
UI-логику приложения (поля ввода, кнопки и т. д.).
y Контроллер: контроллер является посредником между моделью и представлением. Он получает пользовательский ввод от представления, обрабатывает
его (возможно, с обновлением модели) и возвращает результат представлению. Контроллер следит за тем, чтобы представление и модель всегда были
синхронизированы друг с другом. Он становится централизованным обработчиком всех пользовательских взаимодействий, что делает управление этими
взаимодействиями более систематичным и организованным. К обязанностям
контроллера относятся:
обработка пользовательского ввода: получает и интерпретирует команды
пользователя, преобразуя их в действия, выполняемые моделью;
обновление модели: изменяет данные в модели, отправляя ей команды;
обновление представления: изменяет информацию, отображаемую представлением, на основании пользовательского ввода и изменений модели.
Основные преимущества паттерна MVC:
y разделение ответственности: изолируя данные приложения, пользовательский интерфейс и логику управления, MVC способствует модульной
разработке;
y возможность повторного использования: компоненты могут повторно использоваться разными частями приложения и даже разными приложениями;
y удобство обслуживания: паттерн значительно упрощает обновление, тестирование и отладку разных частей приложения;
y гибкость: позволяет разработчикам менять одну часть системы, не влияя на
другие (например, изменить пользовательский интерфейс без изменения
обработки данных).
MVC — мощный архитектурный паттерн, который обеспечивает надежное
управление данными, пользовательским интерфейсом и бизнес-логикой. Он
широко используется в разных средах разработки приложений, от фреймворков
веб-разработки до десктопных приложений, для создания масштабируемых
и простых в обслуживании программ.
Архитектура MVC (Model-View-Controller)
175
Следуя принципам MVC, архитекторы приложений могут создавать структурированные, эффективные и гибкие приложения, более простые в обновлении
и обслуживании. Лучше понять MVC поможет пример.
Применение MVC при проектировании книжного
интернет-магазина
y
y
y
При проектировании интернет-магазина архитектура MVC эффективно обрабатывает сложные взаимодействия между данными книг, пользовательским
интерфейсом и пользовательским вводом, что обеспечивает повышенную
стабильность и масштабируемость системы. Рассмотрим каждый компонент
более подробно.
y Модель: управление данными, относящимися к книгам, авторам, категориям,
отзывам клиентов и т. д. Несколько примеров операций модели:
получение подробной информации о конкретной книге;
обновление складских запасов после покупки;
добавление новой книги в каталог.
y Представление: вывод информации для пользователя в удобном и интерактивном формате. Примеры представлений:
страница со списком книг: выводит список книг с названиями, обложками
и ценами;
страница с подробным описанием книги: выводит подробную информацию
о конкретной книге: автор, описание, отзывы и т. д.;
страница покупательской корзины: позволяет пользователям просматривать, добавлять и удалять отдельные позиции из корзины.
y Контроллер: обрабатывает пользовательские взаимодействия, обновляет
модель по мере необходимости и представление для отражения изменений.
Примеры действий контроллера:
поиск книги: пользователь вводит условие поиска. Контроллер выдает
запрос к модели для поиска книг и обновляет представление для отображения результатов;
добавление в корзину: пользователь щелкает кнопку Add to Cart (Добавить
в корзину); контроллер обновляет модель, чтобы отразить появление
нового товара в корзине; представление обновляется для вывода нового
состояния корзины;
оформление заказа: пользователь решает оформить заказ. Контроллер
обрабатывает транзакцию, обновляет модель (включая складские запасы)
и активирует представление с подтверждением.
Паттерн MVC обеспечивает четкое разделение ответственности, упрощая расширение, обслуживание и тестирование приложений.
176
Глава 4. Паттерны проектирования архитектур решений
Предметно-ориентированное проектирование
Предметно-ориентированное проектирование (DDD, Domain-Driven Design) —
методология и набор практик, направленных на понимание и решение проблем
сложности в программных продуктах. Этот подход используется для проектирования и моделирования программ на основании предметной области (domain),
то есть базовой логики и ключевых концепций бизнеса. За счет использования
единой терминологии и разделения системы на четкие контексты DDD способствует глубокому пониманию пространства задачи и приводит к формированию
решения, точно отражающего фундаментальные потребности бизнеса. Методология DDD особенно полезна в сложных предметных областях, в которых
крайне важно приблизить программу к концепциям реального мира, которые
она представляет.
y
y
y
Рассмотрим DDD на конкретном примере одной предметной области: системы
управления здравоохранением. Представьте, что вы разрабатываете систему для
управления историями болезни, посещениями врачей, курсами лечения, счетами
пациентов и т. д. для медицинской организации. Применение концепций DDD
к этой предметной области могло бы выглядеть так.
y Предметная область: термином «предметная область» обозначается конкретная совокупность проблем, которые призван решить программный продукт.
Логика приложения строится на основе области знаний и действий. Понимание предметной области исключительно важно для создания системы,
действительно удовлетворяющей потребности бизнеса. Для медицинской
организации предметной областью будет управление здравоохранением,
при этом основное внимание будет уделяться пациентам, медицинскому
персоналу, приемам врачей, курсам лечения и выставлению счетов.
y Единый язык: общий язык, совместно используемый разработчиками и нетехническими стейкхолдерами для описания предметной области. Единый
язык нужен для того, чтобы все участники команды одинаково понимали
основные термины и концепции — это снижает риск путаницы и обеспечивает
четкое взаимопонимание с использованием терминов, понятных как профессиональным медикам, так и разработчикам: «пациент», «прием», «лечение»,
«медицинский работник» и т. д.
y Ограниченные контексты: в методологии DDD приложение делится на ограниченные контексты, каждый из которых представляет конкретную обязанность
или функциональность в общей предметной области. Ограниченный контекст
включает все понятия, определения и логику для этой конкретной части предметной области и явно определяет, что находится внутри, а что снаружи его
границ. Например, ограниченный контекст управления пациентами включает
управление данными пациентов, личной информацией, медицинской историей
и т.д. Ограниченный контекст планирования приемов включает управление
приемами, планирование, отмену, перенос записи и т. д., а ограниченный контекст выставления счетов включает обработку платежей, страховку, счета и т. д.
Архитектура MVC (Model-View-Controller)
177
y
y
y
y
y
y
y
y
y
y
y
y
y
y Сущности: эти объекты обладают четкой идентичностью, которая перемеща-
ется по времени и разным состояниям — например, пациенты (с уникальными
идентификаторами) или медицинский персонал (с уникальными учетными
данными).
Объекты-значения: объекты, описывающие характеристики чего-либо, но не
имеющие индивидуальности. Объекты-значения неизменяемы (immutable)
и могут легко замещаться. Примеры — адрес, дата рождения, история болезни
(все эти объекты не имеют индивидуальной идентификации).
Агрегаты: совокупности взаимосвязанных объектов, которые рассматриваются как единое целое для изменений в данных. В агрегате присутствует
корневая сущность, а внешние ссылки ограничиваются этим корнем для
обеспечения целостности. Например, в онлайн-системе управления здравоохранением прием у врача может быть смоделирован как агрегат. Агрегат может
включать сущности и объекты-значения: пациенты (которым назначен прием), медицинские работники (которые будут принимать пациента), кабинеты
(где проходит прием), интервал времени (на которые запланирован прием).
В данном случае сущность «прием» становится корнем агрегата. Любые изменения в категориях «пациент», «медицинский работник», «кабинет» или
«интервал времени» будут осуществляться через сущность «прием». Тем
самым гарантируется, что агрегат «прием» сохранит последовательность
и обеспечит соблюдение всех бизнес-правил, относящихся к приемам врачей.
Репозитории: используются для получения агрегатов с нижележащего уровня хранения данных. Они предоставляют абстракцию, которая позволяет
остальным компонентам приложения взаимодействовать с хранилищем
данных способом, соответствующим модели предметной области. Например,
репозиторий «пациент» используется для получения и управления сущностями «пациент», а репозиторий «прием» — для получения и сохранения
агрегатов «прием».
Фабрики: фабрики отвечают за инкапсуляцию логики создания сложных
объектов и агрегатов. Они обеспечивают создание объектов или агрегатов
в последовательном и действительном состоянии. Например, фабрика «пациент» используется для создания новой сущности «пациент» с действительным
исходным состоянием, а фабрика «прием» — для создания нового агрегата
«прием» с необходимой информацией.
Сервисы: если операция логически не принадлежит объекту-значению или
сущности, она может быть определена как сервис. Сервисы являются частью
модели предметной области и содержат бизнес-логику, оперирующую концепциями предметной области. Например, в контексте «выставление счетов»
сервис выставления счетов содержит такие операции, как вычисление общей
суммы, применение страховочных скидок, формирование счетов и т. д.
События предметной области: события предметной области отражают тот
факт, что в предметной области произошло нечто значительное. Они могут
инициировать другие действия в системе или других системах. Например,
178
Глава 4. Паттерны проектирования архитектур решений
y
событие планирования приема, инициируемое при планировании нового
приема, может оповещать соответствующих медицинских работников, а после успешной оплаты может происходить событие завершения проведения
платежа, которое может инициировать процесс формирования чека.
y Уровень защиты от повреждений (anti-corruption layer, ACL): на нем выполняются преобразования между разными частями системы, использующими
разные языки или модели. Он обеспечивает поддержание целостности каждой модели и обработку несоответствий. Если система выставления счетов
должна взаимодействовать с внешним сторонним платежным шлюзом,
защитный уровень может выполнять преобразование между моделью предметной области в контексте выставления счетов и моделью, используемой
внешней системой.
В системе управления здравоохранением DDD обеспечивает тщательное моделирование и структурирование сложной логики предметной области. Эта
модель способствует совместной работе специалистов сферы здравоохранения
(экспертов предметной области) и разработчиков ПО для создания единого
понимания и языка.
Архитектура системы приближена к реальным операциям здравоохранения
за счет определения четких ограниченных контекстов, сущностей, агрегатов
и других концепций DDD. Такое соответствие гарантирует, что программный
продукт предоставит надежное и гибкое решение, адаптированное для специ
фических потребностей этой предметной области.
Рассмотренный пример показывает, как DDD может стать важным инструментом
для создания сложных, хорошо структурированных систем. DDD фокусируется
на соответствующей предметной области и упрощает взаимодействие между
различными стейкхолдерами.
Обработка зависимостей — важная часть работы в сложных системах. Посмотрим, как обработать зависимость между разными сервисами с помощью
паттерна «Предохранитель», чтобы ошибка в одном сервисе не привела к потере
работоспособности всей системы.
Паттерн Circuit Breaker («Предохранитель»)
В распределенной системе часто отправляются вызовы к нижележащим сервисам, и в ходе вызова может произойти сбой, или сервис может зависнуть вместо
возвращения ответа. Зачастую код многократно повторяет попытки неудачного
вызова. Сложность заключается в том, что исправление удаленного сервиса способно занять минуты или даже часы, а немедленная повторная попытка может
привести к очередному сбою. В результате конечному пользователю приходится
дольше ожидать ответа с ошибкой, пока код многократно совершает вызовы.
Функция повторной попытки потребляет программные потоки и может привести к каскадному сбою.
Реализация паттерна Bulkhead («Переборка»)
179
Паттерн «Предохранитель» (также называют «Прерыватель» или «Переключатель») (Circuit Breaker) проверяет работоспособность нижележащих зависимостей. Он обнаруживает проблемы в этих зависимостях и реализует логику
щадящего отклонения запросов, пока не определит, что зависимость снова работает. Этот паттерн может быть реализован на уровне хранения данных для отслеживания работоспособных и неработоспособных запросов за период времени.
Если определенный процент запросов оказался неработоспособен за этот период
или общее количество исключений превысило пороговое значение (независимо
от процента), «Переключатель» помечается как включенный. В такой ситуации
все запросы выдают исключения, не интегрируясь с зависимостью, в течение
определенного периода тайм-аута. Когда период тайм-аута истечет, небольшая
доля запросов попытается интегрироваться с зависимостью, чтобы проверить,
не восстановилась ли работоспособность. После того как достаточный процент
запросов станет работоспособен за период времени или не будут наблюдаться
ошибки, «Переключатель» снова будет выключен, а запросы продолжат интегрироваться в нормальном режиме.
В основе реализации паттерна лежит конечный автомат, который отслеживает значения или обменивается значениями счетчиков работоспособных/неработоспособных запросов. Информация о состоянии сервисов может храниться в DynamoDB,
Redis/Memcached или другом хранилище данных с низкой задержкой.
Перейдем к архитектурному паттерну Bulkhead («Переборка»), который помогает сократить зависимости между сервисами и взять под контроль ситуацию
в случае получения ошибки сервисом.
Реализация паттерна Bulkhead («Переборка»)
Переборки — элементы конструкции корабля, используемые для создания отдельных водонепроницаемых отсеков. Их основное назначение — ограничить
последствия пробоины в корпусе, чтобы вода не распространялась по всему
судну. Такая конструкция критически важна для обеспечения безопасности,
минимизируя риск затопления всего корабля при получении повреждения.
Аналогичная концепция помогает ограничить последствия сбоев в архитектуре
больших систем, которые желательно секционировать для ослабления зависимостей между сервисами. Идея заключается в том, что один сбой не должен
приводить к сбою всей системы, как показано на рис. 4.10.
Сервис 1
Сервис 2
Сервис 3
Сервис 1
Сервис 2
Сервис 3
Пул 1
Сервис 3
Пул 1
Рис. 4.10. Паттерн «Переборка»
180
Глава 4. Паттерны проектирования архитектур решений
y
y
y
y
В паттерне «Переборка» элементы приложения изолируются в пуле сервисов,
который имеет высокую зависимость; в случае сбоя одного элемента другие продолжают обслуживать последующие сервисы. На рис. 4.10 сервис 3 разбивается
на два пула. Если в сервисе 3 произойдет сбой, то последствия для сервиса 1
или сервиса 2 будут определяться их зависимостью от пула, но это не означает
выхода из строя всей системы. Ниже перечислены важные обстоятельства, которые необходимо учитывать при внедрении паттерна «Переборка», особенно
в модель общих сервисов.
y Приложение не должно выходить из строя из-за сбоя одного сервиса.
y Определите, приемлемо ли менее эффективное использование ресурсов. Проблемы с производительностью в одном сегменте должны быть переносимы
приложением в целом.
y Выберите полезную детализацию. Проследите, чтобы пулы сервисов были
управляемыми и справлялись с нагрузкой приложения.
y Отслеживайте производительность каждого сегмента сервисов и придерживайтесь условий SLA. Убедитесь, что все подвижные части работают вместе,
и протестируйте приложение при выходе из строя одного пула сервисов.
Определите сегмент сервиса для каждого требования — технического или бизнес-требования. Паттерн должен предотвращать каскадные сбои в приложениях
и изолировать критических потребителей от стандартных.
Серверы старых приложений часто имеют конфигурацию с жестко закодированными IP-адресами или именами DNS. Чтобы модернизировать и обновить
сервер, необходимо изменить все приложение и провести его повторную
проверку. В таких случаях адрес сервера должен оставаться неизменным.
В следующем разделе вы узнаете, как в такой ситуации может помочь паттерн
«Плавающий IP».
Создание паттерна 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.
Amazon Route 53
Amazon Route 53
Адрес Elastic IP
ENI (Elastic Network
Interface)
Рис. 4.11. Паттерн «Плавающий IP»
Поскольку переносится EIP, обновление DNS может не потребоваться. EIP
может перемещать публичный IP-адрес сервера между экземплярами. Если
вам нужно переместить и публичные, и частные IP-адреса, используйте более
гибкий механизм — например, ENI (показанный в правой части диаграммы).
ENI может перемещаться между экземплярами, и можно использовать один
публичный и частный адрес для маршрутизации трафика или обновления
приложения.
Мы рассмотрели несколько архитектурных паттернов с развертыванием приложений на виртуальной машине. Однако при использовании виртуальной машины
вам может понадобиться помощь. Чтобы оптимизировать эксплуатацию, можно
развертывать приложение в контейнерах. Контейнеры лучше всего подходят
для развертывания микросервисов. В следующем разделе рассматривается развертывание на основе контейнера.
182
Глава 4. Паттерны проектирования архитектур решений
Развертывание приложения в контейнере
В мире постоянно изобретаются новые языки программирования, развиваются
новые технологии. Разные технологические стеки приложений требуют разных
аппаратных и программных сред развертывания. Часто возникает необходимость
в выполнении приложений на разных платформах и миграции между платформами. Решения требуют формата, который может выполняться где угодно и при
этом является целостным, легковесным и портируемым.
Подобно тому как транспортные контейнеры стандартизируют перевозку грузов, программные контейнеры стандартизируют транспортировку приложений.
Платформа Docker — инструмент, который упаковывает в контейнер всё, что
может понадобиться приложению для запуска: структуру файловой системы,
демоны, библиотеки и зависимости. Контейнеры обеспечивают изоляцию программного продукта в соответствующей среде разработки и промежуточной
(стейдж) среде. Такая изоляция чрезвычайно важна, поскольку она предотвращает возникновение конфликтов при запуске разных приложений разными
командами в одной базовой инфраструктуре.
Виртуальные машины (VM) изолируются на уровне операционной системы,
а контейнеры — на уровне ядра. Такая изоляция позволяет нескольким приложениям выполняться в однохостовой ОС, но при этом иметь собственные
файловые системы, хранилище данных, оперативную память, библиотеки и, что
самое главное, собственное представление системы.
Приложение X
на VM 1
Двоичные файлы /
библиотеки
Гостевая ОС
Приложение Y
на VM 2
Приложение Z
на VM 3
Двоичные файлы / Двоичные файлы /
библиотеки
библиотеки
Гостевая ОС
Гостевая ОС
Приложе- Приложе- Приложе- Приложе- Приложе- Приложение X
ние X
ние Y
ние Y
ние Z
ние Z
Двоичные файлы /
библиотеки
Двоичные файлы /
библиотеки
Гипервизор
Менеджер контента (например, Docker)
ОС хоста
ОС хоста
Сервер (хост)
Виртуальная машина
Сервер (хост)
Контейнеры
Рис. 4.12. Виртуальные машины и контейнеры
для развертывания приложений
Развертывание приложения в контейнере
183
Как показано на рис. 4.12, контейнеры позволяют развернуть несколько приложений на одной виртуальной машине. Каждое приложение располагает
собственной средой выполнения, так что можно запускать много отдельных
приложений при одном и том же количестве серверов. Контейнеры совместно
используют ядро операционной системы на машине. Они предоставляют такие
преимущества, как быстрый запуск и эффективное потребление вычислительных ресурсов (например, оперативной памяти). Образы контейнеров строятся
с учетом уровней файловой системы и могут совместно использовать общие
файлы. Совместно используемые ресурсы сокращают нагрузку на диск и ускоряют процесс загрузки образов контейнеров.
Почему популярность контейнеров растет и какими преимуществами они обладают?
Преимущества контейнеров
y
y
Когда речь заходит о контейнерах, часто возникают следующие вопросы.
y Зачем нужны контейнеры, если есть экземпляры?
y Разве экземпляры не обеспечивают изоляции от базового оборудования?
Вопросы вполне резонные, но такая система, как Docker, дает целый ряд преимуществ. Одно из них — возможность полноценного использования ресурсов
виртуальной машины за счет размещения нескольких приложений (на разных
портах) в одном экземпляре.
Docker использует некоторые возможности ядра Linux (а именно пространства
имен ядра и группы) для достижения полной изоляции между своими процессами, как показано на рис. 4.13.
y
y
y
Как следует из диаграммы, на одной машине могут выполняться два и более
приложения, требующих разных версий среды выполнения Java, поскольку
каждая конфигурация Docker имеет собственную версию Java и набор установленных библиотек. В свою очередь, уровень контейнеров в инфраструктуре
приложения упрощает декомпозицию приложения на микросервисы, которые
могут выполняться параллельно на одном экземпляре. Назовем основные
преимущества контейнеров.
y Портируемая среда выполнения приложений: контейнеры предоставляют
платформенно-независимую функциональность. Вы строите приложение
один раз и развертываете его где угодно независимо от используемой операционной системы.
y Ускорение циклов разработки и развертывания: изменяйте приложение
и запускайте его где угодно с быстрым временем загрузки (обычно в пределах
нескольких секунд).
y Пакетные зависимости и приложение в одном артефакте: упакуйте код вместе с библиотеками и зависимостями, чтобы запускать приложение в любой
операционной системе.
184
Глава 4. Паттерны проектирования архитектур решений
y
y Запуск разных версий приложения: приложения с разными зависимостями
выполняются одновременно на одном сервере.
y
y Возможность полной автоматизации: управление контейнерами и разверты-
y
y
ванием осуществляется при помощи скриптов, что способствует снижению
затрат и риска ошибок.
y Повышение эффективности использования ресурсов: контейнеры обеспечивают эффективное масштабирование и высокую доступность; на серверах
приложения можно развернуть сразу несколько копий одного контейнера.
y Простота управления безопасностью: контейнеры зависят от платформы,
а не от приложения.
Приложение
Приложение
Приложение
Контейнер
Контейнер
Контейнер
Среда
Ядро ОС
Операционная система хоста ОС
Физический сервер
Рис. 4.13. Уровень контейнеров в инфраструктуре приложений
Контейнерное развертывание становится очень популярным благодаря своим
преимуществам.
Существует много способов организации контейнеров. Рассмотрим контейнерное
развертывание более подробно.
Контейнерное развертывание
Сложные приложения с несколькими микросервисами можно быстро развернуть
с помощью механизма контейнерного развертывания. С контейнерами построение и развертывание приложения становятся более управляемыми, так как среда
остается неизменной. Постройте контейнер в режиме разработки, переведите
Развертывание приложения в контейнере
185
его в среду тестирования, а затем выпустите на продакшен. Контейнерное развертывание особенно полезно в гибридных облачных средах. С контейнерами
проще поддерживать согласованность сред между микросервисами. Так как
микросервисы не всегда поглощают много ресурсов, их можно разместить в одном экземпляре для сокращения затрат.
Иногда клиенты используют короткие рабочие процессы, требующие создания
временных сред. Такими средами могут быть системы очередей или задания
непрерывной интеграции, которые не всегда эффективно используют ресурсы
сервера. Сервисы оркестрации контейнеров (такие, как Docker или Kubernetes)
могут стать хорошим обходным решением, позволяющим создавать контейнеры
в экземпляре и удалять их оттуда.
Платформа легковесной контейнерной виртуализации Docker предоставляет инструменты управления приложениями. Для запуска контейнеров ее автономную
версию можно установить на любом компьютере. Kubernetes — сервис оркестрации
контейнеров, работающий с Docker и другой контейнерной платформой. Kubernetes
поддерживает автоматизированное управление контейнерами и качественно реализует аспекты безопасности, сетевых коммуникаций и масштабирования.
Контейнеры помогают компаниям создавать больше объектно-ориентированных
рабочих нагрузок, и провайдеры публичных облачных платформ (такие, как
AWS) расширяют сервисы для управления контейнерами Docker и Kubernetes.
На рис. 4.14 представлено управление контейнерами Docker с использованием
сервиса Amazon ECS (Elastic Container Service). Это полностью управляемый
эластичный сервис для автоматизации масштабирования и координации контейнеров Docker.
Экземпляры EC2
ЗАДАЧА
Интернет
Балансировщик
нагрузки
ЗАДАЧА
АГЕНТ
ECS
Контейнер
Контейнер
ЗАДАЧА
ЗАДАЧА
АГЕНТ
ECS
Балансировщик
нагрузки
Контейнер
Контейнер
ЗАДАЧА
ЗАДАЧА
АГЕНТ
ECS
Контейнер
Контейнер
Рис. 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.
Облако AWS
VPC
Amazon S3
Route 53
Зона доступности 2
Зона доступности 1
Публичная подсеть
Балансировщик нагрузки Elastic Load Balancer
Частная подсеть
Контейнеры
Amazon EKS Kubernetes cluster
Контейнеры
ElastiCache для Redis
Amazon
CloudFront
Amazon EKS Kubernetes cluster
Частная подсеть
Amazon RDS
Уровень базы данных
Резервный экземпляр базы данных
Пользователи
Рис. 4.15. Развертывание приложения с состоянием в контейнере
y
Как показано на диаграмме, архитектура на базе контейнеров включает несколько
ключевых компонентов:
y Amazon Virtual Private Cloud (VPC) с определенными подсетями.
публичная подсеть: обеспечивает хостинг балансировщика нагрузки;
частные подсети: используются для развертывания приложения и базы
данных;
балансировщик нагрузки: отвечает за обеспечение доступа к веб-сайту,
размещенному в его контейнерах;
кластер Amazon Elastic Kubernetes Service (EKS): представляет управляемую группу узлов в Kubernetes. Эти узлы отвечают за работу нескольких
контейнеров приложений;
база данных Amazon ElastiCache Redis: используется для хранения состояния пользовательской сессии.
Эта архитектура позволяет масштабировать приложение за счет хранения
пользовательских сессий в базе данных Redis. Заметим, что реализация этого
решения может потребовать изменений в коде приложения, что может оказаться
неприемлемым в некоторых сценариях.
188
Глава 4. Паттерны проектирования архитектур решений
Вы познакомились с различными архитектурными паттернами, ориентированными на разработку приложений. Теперь поговорим о данных. Они являются
неотъемлемой частью проектирования любой архитектуры, и бˆольшая часть
архитектуры сосредоточена на сборе, хранении и визуализации данных. В следующем разделе более подробно рассматривается работа с данными в архитектуре
приложения.
Работа с базой данных в архитектуре приложения
Данные играют центральную роль в разработке любого приложения, и их
масштабирование всегда создает немало проблем. Эффективная работа
с данными снижает задержку и повышает производительность приложения.
В разделе «Построение архитектуры на базе кэша» вы узнали, как повысить
эффективность получения часто запрашиваемых данных за счет размещения
кэша перед базой данных (паттерн «Кэширование на уровне приложения»).
Вы можете разместить перед базой данных кэш Memcached или Redis, что
позволит избежать большого количества обращений к базе данных и снизить
задержку получения данных.
С ростом числа пользователей приложения приходится обрабатывать большие
объемы данных при работе с реляционной БД. Вам придется увеличить объем
хранилища либо провести вертикальное масштабирование сервера базы данных
с установкой дополнительной памяти или повышением мощности процессора.
Если говорить о горизонтальном масштабировании, то оно оказывается более
сложным в контексте реляционных баз данных. В приложениях с интенсивным
чтением горизонтальное масштабирование может обеспечиваться созданием
реплики для чтения. Все запросы на чтение направляются репликам для чтения,
а узел основной базы данных обслуживает запросы на запись и обновление.
Так как реплика для чтения использует асинхронную репликацию, это может
создать задержку. Вариант с репликами для чтения выбирается в случаях, когда
в приложении допустимы миллисекундные задержки.
Шардирование баз данных применяется для создания схемы «ведущий — ведущий» (multi-master) реляционной базы данных и для внедрения концепции
горизонтального масштабирования. Метод шардирования используется для
улучшения производительности записи с несколькими серверами баз данных.
База данных структурируется и сегментируется на идентичные разделы, при
этом соответствующие столбцы таблицы служат ключами для распределения
процесса записи.
Как показано на рис. 4.16, клиентская база данных может быть разделена на
несколько сегментов.
Как показано на диаграмме, без шардов все данные находятся в одном разделе —
например, имена всех пользователей хранятся в одной базе данных. При шардировании данные разбиваются на большие блоки, называемые шардами.
189
Развертывание приложения в контейнере
апример, имена всех пользоН
вателей, начинающиеся на
буквы от A до I, хранятся в одной базе данных, от J до R —
в другой, и от S до Z — в третьей. Во многих сценариях
шардирование обеспечивает
более высокую производительность и операционную
эффективность.
Применение Amazon RDS для
шардирования БД на бэкенде подразумевает установку
соответствующего ПО (например, MySQL) с системой
хранения данных Spider на экземпляре Amazon EC2. Следовательно, можно начать с со
здания нескольких баз данных
RDS и использовать их для
шардирования на бэкенде.
я
Им
тA
=о
до I
Шард 1
Amazon RDS
MySQL
Имя = от J до R
ПО
сегментации
Шард 2
Amazon EC2
Им
я=
Amazon RDS
MySQL
от S
до
Z
Шард 3
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 C. Martin). Паттерн выводит
на первый план разделение ответственности, удобство обслуживания и тестируемость. Он направлен на создание гибкой, хорошо адаптируемой и простой
в обслуживании системы.
В паттерне «Чистая архитектура» приложение делится на пять ключевых компонентов. Пример с книжным интернет-магазином поможет понять их смысл.
1. Сущности (внутренний уровень): бизнес-объекты, инкапсулирующие базовые бизнес-правила. Они не зависят от конкретных технологий, баз данных
или фреймворков. Сущности представляют «предметы» в системе и их возможности. В книжном интернет-магазине сущность «книга» может иметь
свойства (название, автор, цена и т. д.) и методы для проверки ее наличия
или применения скидок.
2. Сценарии использования содержат правила, специфические для приложения,
и определяют, как сущности взаимодействуют друг с другом для реализации
конкретных сценариев или историй пользователей. Они координируют поток
данных и действия между сущностями и внешними интерфейсами. Сценарии
использования нейтральны по отношению к технологиям, они сосредоточены
только на бизнес-логике. Например, сценарий использования «Оформление
заказа» может включать проверку покупательской корзины, применение
скидок, вычисление стоимости доставки и обработку платежа.
3. Интерфейсы (порты): интерфейсы определяют контракты для взаимодействий между разными уровнями системы. Они создают границу, отделяющую
внутренние уровни (сущности, сценарии использования) от внешних (адаптеров, фреймворков, драйверов). Такое разделение обеспечивает гибкость и простоту обслуживания. Например, может существовать интерфейс обработки
платежей, который определяет методы для перечисления и возврата средств.
192
Глава 4. Паттерны проектирования архитектур решений
4. Адаптеры реализуют интерфейсы и выполняют преобразования между внутренними и внешними уровнями. Они позволяют приложениям
взаимодействовать с такими внешними компонентами, как базы данных,
API и сторонние библиотеки. Адаптеры позволяют изолировать базовую
логику от технологических изменений или внешних зависимостей. Адаптер
базы данных может реализовать интерфейс обращения к данным, который
будет обеспечивать взаимодействие с конкретной технологией базы данных.
5. Фреймворки и драйверы (внешний уровень): этот уровень включает все
технические подробности и инструменты, используемые для построения
приложения. К нему относятся веб-серверы, базы данных, UI-фреймворки,
сторонние библиотеки и т. д. Этот уровень взаимодействует с адаптерами
для соединения базового приложения с внешним миром. Такое соединение
может включать реализацию RESTful-API, использующего конкретный вебфреймворк, создание подключения к базе данных SQL или интеграцию со
сторонним платежным шлюзом.
В паттерне «Чистая архитектура» каждый уровень существует независимо от
других, что позволяет вносить изменения на одном уровне, не оказывая влияния
на другие. Менять базы данных, UI-фреймворк или бизнес-логику можно без
каскадных эффектов в системе. Так как архитектура имеет четко определенные
интерфейсы, вам будет проще создавать моки (mocks) или заглушки (stubs) для
тестирования. Базовая бизнес-логика может тестироваться независимо от баз
данных, UI или других внешних зависимостей.
При использовании паттерна «Чистая архитектура» старайтесь избегать проблемы избыточного проектирования (over-engineering). Для небольших или
простых проектов затраты на реализацию этой архитектуры могут не окупаться.
Перед применением тщательно оцените, оправдывают ли преимущества паттерна
возросшую сложность и увеличение времени разработки.
Паттерн «Чистая архитектура» предоставляет надежную и гибкую основу для
разработки программных продуктов, способных адаптироваться к изменениям
технологий и требований. Ориентация на разделение ответственности и четкие
границы между уровнями улучшают масштабируемость и удобство обслуживания и тестирования. Это мощный паттерн, который может хорошо работать
в сложных системах, но должен применяться с пониманием потребностей и контекста конкретного проекта, чтобы избежать излишнего усложнения.
Итак, мы рассмотрели разные архитектурные паттерны и практики. Теперь
рассмотрим важнейшие антипаттерны, о которых необходимо помнить при
проектировании архитектуры приложения.
Как избежать антипаттернов в архитектуре решений
В этой главе вы узнали о новых способах проектирования архитектуры решений с разными паттернами проектирования. Часто команды могут отклоняться от лучших практик из-за нехватки времени или ресурсов. Старайтесь
Развертывание приложения в контейнере
193
y
y
y
y
y
по возможности избегать перечисленных ниже антипаттернов проектирования архитектур. Антипаттерны служат признаком плохо спроектированных
систем.
y Масштабирование осуществляется реактивно и вручную. Когда серверы приложений достигают максимальной емкости и у них не остается доступных
ресурсов, у пользователей прерывается доступ к приложениям. Администратор узнает о проблемах, только когда пользователи начинают сообщать о них.
После этого администратор инициирует процесс запуска нового экземпляра
сервера для снижения нагрузки на существующие. Но у такого решения есть
недостаток — между запуском экземпляра и его фактической доступностью
обычно существует задержка в несколько минут. В этот промежуточный
период пользователи могут сталкиваться с прерываниями в обслуживании
и не могут обращаться к приложению. Следует действовать проактивно
и использовать автомасштабирование для добавления вычислительных
мощностей при достижении сервером определенного порога — например,
60 % загрузки процессора или 60 % использования памяти.
y Отсутствует автоматизация. В случае сбоев серверов приложений администратор вручную запускает и настраивает новый сервер и вручную оповещает
пользователей. Автоматизация обнаружения нерабочих ресурсов и запуск
ресурсов-заменителей может упростить эксплуатацию. Кроме того, можно
добавить автоматические уведомления при таких изменениях ресурсов.
y Сервер в течение долгого времени поддерживается с жестко закодированными IP-адресами, что препятствует гибкости. Со временем это ведет к рассогласованию конфигураций серверов и, как следствие, неэффективному
распределению ресурсов и к ситуации, когда некоторые ресурсы работают,
когда они не нужны. Желательно, чтобы все серверы были идентичны и имели
возможность переключиться на новый IP-адрес. Все неиспользуемые ресурсы
должны автоматически завершать работу.
y Приложение строится монолитно, а все уровни архитектуры, включая вебуровень, уровень приложения и уровни данных, тесно связаны и зависят от
сервера. Если на одном из серверов происходит сбой, ломается все приложение. Поддерживайте уровень приложения и веб-уровень независимыми; для
этого между ними необходимо добавить балансировщик нагрузки. В случае,
если один из серверов приложения окажется недоступным, балансировщик
нагрузки автоматически перенаправит весь трафик на оставшиеся работоспособные серверы.
y Приложение жестко связано с сервером, а серверы напрямую обмениваются
данными друг с другом. Аутентификация пользователей и сессии хранятся
на сервере локально, а все статические файлы предоставляются с локального
сервера. Создайте сервис-ориентированную RESTful-архитектуру, в которой
сервисы взаимодействуют друг с другом по стандартному протоколу (такому,
как HTTP). Аутентификация пользователей и сессии должны храниться
в распределенном хранилище с низкой задержкой для горизонтального
194
Глава 4. Паттерны проектирования архитектур решений
y
y
y
y
масштабирования приложения. Статические ресурсы должны храниться
в централизованном хранилище объектов, отделенном от сервера.
y Одна реляционная база данных используется для всех потребностей, что
создает проблемы с производительностью и задержку. Создайте подходящее
хранилище для разных задач:
NoSQL для хранения пользовательских сессий;
кэш-хранилище данных для доступности данных с низкой задержкой;
хранилище данных для потребностей отчетности;
реляционную базу данных для транзакционных данных.
y В системе присутствует единая точка отказа, а один экземпляр базы данных
обслуживает все приложение. По возможности постарайтесь исключить из
архитектуры единые точки отказа. Установите вторичный сервер (резервный)
и выполните репликацию данных. В случае сбоя основного сервера базы
данных вторичный сервер может принять его рабочую нагрузку.
y Статический контент (например, графика в высоком разрешении и видео)
предоставляется непосредственно с сервера без кэширования. Рассмотрите
возможность использования CDN для кэширования тяжеловесного контента
рядом с местоположением пользователя; это поможет сократить задержку
и время загрузки страницы.
y В системе присутствуют дефекты безопасности, открывающие доступ
к серверу без детализированной политики безопасности. Всегда приме
няйте принцип наименьших привилегий; это означает, что изначально
доступ запрещен и предоставляется только явно указанной группе пользователей.
В списке перечислены некоторые наиболее распространенные антипаттерны.
В этой книге вы изучите лучшие практики, позволяющие избежать антипаттернов при проектировании решений.
Итоги
В этой главе рассматривалось построение надежных и масштабируемых программных архитектур с помощью различных архитектурных парадигм. Глава
началась с исследования n-уровневой архитектуры и анализа ее основных
компонентов: веб-уровня, уровня приложения и уровня базы данных. Далее
мы обсудили мультитенантную архитектуру SaaS (Software as a Service) и изу
чили сложности и преимущества объединения разных пользовательских баз
в единой структуре.
Применительно к веб-сервисам в главе был рассмотрен архитектурный стиль
RESTful и приведено подробное описание его принципов и сценариев применения. Затем мы перешли к построению RESTful-архитектуры интернет-магазина,
получив возможность изучить практический пример реализации.
Итоги
195
После этого мы рассмотрели архитектуры с применением кэширования. Мы
подробно изучили распределение кэшей, паттерны с прокси-серверами (кэширующий прокси-сервер, заменяющий прокси-сервер) и эффективные стратегии
кэширования (например, кэширование приложений). Сравнительный анализ
Memcached и Redis помогает сделать выбор оптимального решения для кэширования.
Значимость архитектурных паттернов была подчеркнута в описаниях паттерна
MVC (модель — представление — контроллер) и методологии DDD (предметно-ориентированное проектирование), позволяющих архитекторам создавать
структурированные, адаптируемые и управляемые системы.
Устойчивость архитектуры была подробно рассмотрена в описании паттерна «Предохранитель» (Circuit Breaker) и реализации паттерна «Переборка»
(Bulkhead) для повышения стабильности системы. Знакомство с паттерном «Плавающий IP» расширяет инструментарий для обеспечения высокой доступности.
Далее в главе была рассмотрена тема контейнеризации, с описанием преимуществ и планов эффективного развертывания контейнеров. При разговоре об
архитектуре приложений были затронуты стратегии работы с базой данных
и описаны паттерны высокой доступности для обеспечения целостности данных
и непрерывной эксплуатации.
В завершение главы мы коснулись принципов чистой архитектуры и стратегий
избежания антипаттернов в архитектуре решений.
В ходе этого исследования вы получили глубокое представление об особенностях
построения адаптируемых, масштабируемых и перспективных программных
систем. Теперь у вас есть знания, необходимые для того, чтобы лучше ориентироваться в непрерывно изменяющейся среде современных технологий.
ГЛАВА 5
ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
ОБЛАЧНО-ОРИЕНТИРОВАННЫХ
АРХИТЕКТУР
В эпоху стремительной цифровой трансформации бизнес все чаще переходит
на облачные платформы для построения масштабируемых, устойчивых и экономически эффективных решений. Переход на облачно-ориентированные
архитектуры становится стратегической необходимостью для организаций,
стремящихся к динамичности, инновациям и эффективной эксплуатации.
В этой главе будет рассмотрен процесс проектирования и реализации облачно-ориентированных архитектур, с особым вниманием к паттернам, дизайну
и лучшим практикам.
Мы подробно поговорим о разных облачно-ориентированных паттернах, включая
принципы проектирования и реальные примеры. Обсудим также антипаттерны
облачно-ориентированных архитектур и практики, которые следует избегать.
y
y
y
y
y
y
y
y
y
y
В этой главе рассматриваются следующие темы.
y Что такое облачно-ориентированная архитектура?
y Бессерверная архитектура.
y Архитектурные решения с сохранением и без сохранения состояния.
y Микросервисная архитектура.
y Реактивная архитектура.
y Архитектура на базе очереди.
y Архитектура «Каналы и фильтры»
y Архитектура, управляемая событиями.
y Паттерн BFF (Backend for Frontend).
y Антипаттерны облачно-ориентированных архитектур.
К концу главы вы получите прочное понимание паттернов облачно-ориентированных архитектур и будете готовы к проектированию, построению и оптимизации облачно-ориентированных решений.
Что такое облачно-ориентированная архитектура
197
Что такое облачно-ориентированная
архитектура
В главе 3 «Миграция на облачные платформы и проектирование облачных архитектур» были представлены разные стратегии облачной миграции, включая
lift-and-shift, смену платформы, повторную покупку, удаление и т. д. Чтобы
пользоваться всеми преимуществами и моделями ценообразования облака, очень
важно принять облачно-ориентированную архитектуру. Облачно-ориентированной архитектурой называется методология проектирования для построения
и запуска приложений, которые в полной мере используют преимущества и возможности облачных вычислений. Она подразумевает построение приложений,
обеспечивающих эффективность, масштабируемость и устойчивость в динамических облачных средах.
y
y
y
y
y
Облачно-ориентированные приложения разрабатываются на базе принципов,
по максимуму использующих облачные сервисы, автоматизацию и современные
практики разработки. Назовем ключевые характеристики облачно-ориентированных архитектур.
y Микросервисы: облачно-ориентированные архитектуры часто строятся из
небольших слабосвязанных сервисов, которые называются микросервисами.
Каждый микросервис обеспечивает определенную бизнес-функциональность
и может разрабатываться, развертываться и масштабироваться независимо.
y Бессерверные вычисления: облачно-ориентированные приложения часто
используют бессерверные вычисления для достижения бесшовной масштабируемости и сокращения затрат. Этот подход позволяет разработчикам
сосредоточиться на коде и логике приложения, не беспокоясь об управлении серверами. Это делает возможным автоматическое масштабирование
и эффективное использование ресурсов, что может значительно снизить
эксплуатационные затраты. В бессерверной архитектуре приложения упаковываются вместе с их зависимостями, что обеспечивает согласованность
разных сред. Это упрощает бесшовное развертывание, масштабирование
и портируемость приложений.
y Эластичность и масштабируемость: облачно-ориентированные приложения
могут масштабироваться в зависимости от текущей потребности, обеспечивая
эффективное использование ресурсов и экономию средств. Это достигается
посредством автоматического масштабирования и распределения нагрузки.
y Устойчивость и отказоустойчивость: облачно-ориентированные приложения проектируются с расчетом на отказоустойчивость. Они включают такие
практики, как избыточность, автоматизация восстановления и механизмы
отказоустойчивости для обеспечения непрерывности работы даже при возникновении сбоев.
y Автоматизация: в облачно-ориентированных архитектурах применяется автоматизация различных процессов, включая развертывание, масштабирование,
198
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
y
y
y
y
мониторинг и восстановление. Автоматизация сокращает объем ручного вмешательства, повышает эффективность и снижает риск человеческих ошибок.
y Практики DevOps: облачно-ориентированное развертывание способствует
тесному сотрудничеству между командами разработки и эксплуатации. Таким образом формируется культура непрерывной интеграции, непрерывной
поставки и быстрых итераций.
y Отсутствие состояния: облачно-ориентированные приложения про
ектируются как приложения без сохранения состояния. Это означает,
что их компоненты не зависят от локального состояния сервера. Такой
подход улучшает масштабируемость и упрощает горизонтальное масштабирование.
y API на первом плане: API (программные интерфейсы) играют чрезвычайно
важную роль в облачно-ориентированных архитектурах. Приложения проектируются с четкими и хорошо документированными API, что делает возможными коммуникации между микросервисами и способствует интеграции
с другими сервисами.
y Непрерывный мониторинг и улучшение: в ходе работы облачно-ориентированных приложений осуществляется непрерывный мониторинг, обеспечивающий оптимальную производительность и надежность. Информация,
основанная на данных, используется для выявления потенциальных областей
с целью улучшения и оптимизации.
При миграции приложений в облако не ставится задача переместить их в текущем
виде. Переход в облако позволяет оптимизировать приложение, в полной мере
воспользовавшись преимуществами облачных платформ, в первую очередь —
моделью оплаты по факту потребления. Это означает, что вы платите только за
те ресурсы, которые фактически использовались. Таким образом обеспечиваются
эластичность и экономическая эффективность, так как появляется возможность
масштабирования в зависимости от потребностей без вложений в фиксированную инфраструктуру.
Очень важно тщательно планировать ресурсы, чтобы избежать их чрезмерного
выделения и лишних затрат. Приложение можно развернуть ближе к пользователям в разных регионах, чтобы сократить задержку и улучшить взаимодействие
с пользователями. Глобальная доступность облака позволяет охватить более
широкую аудиторию без вложений в открытие физических дата-центров по
всему миру.
Переход с капитальных расходов (CapEx) на эксплуатационные (OpEx) — важное финансовое преимущество облачных решений. Вместо серьезных вложений
в оборудование и обслуживание на начальном этапе затраты распределяются
во времени. Такой подход облегчает планирование бюджета и позволяет более
эффективно распределять ресурсы. С другой стороны, с распределенными
командами и приложениями управление затратами усложняется. Необходимо
принимать эффективные меры управления затратами в разных командах.
Что такое облачно-ориентированная архитектура
199
Облачно-ориентированная архитектура позволяет организациям пользоваться
всеми преимуществами облачных вычислений, включая масштабируемость,
гибкость и экономическую эффективность. В качестве примера возьмем стриминговый мультимедиасервис, чтобы вы увидели отличительные особенности
и преимущества облачно-ориентированных архитектур с бессерверной схемой
по сравнению с локальными архитектурами.
В объектно-ориентированных архитектурах стриминговое приложение проектируется с использованием микросервисов и бессерверных вычислений. Разные
функции приложения (аутентификация, рекомендации контента, кодирование
видео, хранение данных и т. д.) разрабатываются как отдельные микросервисы.
Эти микросервисы инкапсулируются в бессерверных функциях, чтобы выполняться в ответ на определенное событие, или триггер. Например, функции
кодирования видео могут автоматически вызываться при отправке нового видео, а функции рекомендации контента могут реагировать на пользовательские
взаимодействия. Управляемые облачные сервисы работают с базами данных,
обеспечивают хранение, аутентификацию и даже выполнение бессерверных
функций.
В локальной архитектуре приложение размещается на серверах и инфраструктуре компании. Монолитное приложение решает все задачи, включая аутентификацию, поставку контента и обработку видео. Масштабирование требует
ручного вмешательства и приобретения дополнительного оборудования.
Переходя на облачно-ориентированную разработку, важно помнить о потенциальном риске привязки к провайдеру. Это означает, что архитектура, спроектированная с платформенными инструментами и сервисами конкретного облачного
провайдера (например, AWS), может быть с трудом перенесена на платформу
другого провайдера из-за уникальной, проприетарной природы возможностей
каждой платформы. Сервисы на разных платформах могут иметь разные имена, а методы для вызова этих сервисов могут значительно различаться. Хотя
облачно-ориентированная функциональность предоставляет мощные возможности для оптимизации операций на конкретной платформе, она также может
создавать проблемы, если позднее вы решите сменить облачного провайдера.
Тщательно следите за балансом между использованием расширенных возможностей и поддержанием независимости от платформы.
Переход на облачно-ориентированную архитектуру с бессерверной схемой
имеет ряд преимуществ перед традиционными локальными конфигурациями.
Благодаря сочетанию микросервисов и бессерверных вычислений приложения
демонстрируют высокую производительность и масштабируемость, обеспечивают экономическую эффективность и быстроту инноваций, при этом сохраняя устойчивость и отклик в реальном времени на динамические потребности
пользователей.
Рассмотрим бессерверную архитектуру более подробно.
200
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Бессерверная архитектура
Когда вы разрабатываете приложение по традиционному сценарию, необходим
сервер, на котором установлена нужная операционная система и нужные программы. При написании кода следует убедиться, что сервер работает. В процессе развертывания надо добавить больше серверов, чтобы не отставать от
потребностей пользователей, а также обеспечить механизмы масштабирования
(например, автомасштабирование), чтобы управлять требуемым количеством
серверов для обслуживания запросов пользователей. В такой ситуации значительные усилия тратятся на управление инфраструктурой и ее обслуживание,
а это не имеет никакого отношения к бизнес-задаче.
Термин «бессерверный» означает, что для размещения кода не нужен сервер,
и это освобождает вас от забот по автомасштабированию, а также ослабляет связи
и снижает затраты. Переход на бессерверную схему позволяет сосредоточиться
на приложении и писать код для реализации функциональности, не беспокоясь
об обслуживании инфраструктуры.
Когда речь заходит о бессерверной схеме применительно к AWS, первое,
что приходит в голову, — функции AWS Lambda; это сервис FaaS (Function as a
Service), предоставляемый облачной платформой AWS. Чтобы приложение
было сервис-ориентированным, Amazon API Gateway дает возможность
размещения конечных точек RESTful перед функциями AWS Lambda, что
помогает предоставлять доступ к ним как к микросервисам. Amazon DynamoDB
предоставляет высокомасштабируемую базу данных NoSQL, полностью
бессерверное хранилище данных NoSQL, а 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
Запрос к вебсайту опросов
через
HTTPS
Клиент
Страница HTML
совершает
вызов AJAX
Amazon S3
предоставляет
защищенную
страницу опроса
в формате HTML
Триггер
события
Amazon API
Gateway
Функция Lambda
обрабатывает
данные запроса
Вызовы API регистрируются
в AWS CloudTrail
Репозиторий
результатов Amazon S3
Метаданные
нешифрованного
опроса (без
персональных
данных)
Репозиторий
метаданных опросов
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) создают скрытую абстрактную прослойку, которая динамически запускает серверы по мере необходимости. Иногда этот процесс требует
времени, что приводит к задержке («холодному старту») при вызове функции
после длительного бездействия. Важно учитывать проблемы «холодного старта»
при проектировании бессерверной архитектуры и реализовать стратегии для их
преодоления, чтобы приложение быстро реагировало и работало эффективно.
y
y
y
Рассмотрим практический пример: разработку системы уведомлений в реальном
времени для платформы социальной сети. Система должна отправлять мгновенные уведомления на устройства пользователя каждый раз, когда он получает
лайки, комментарии или запрос на добавление в друзья. Ниже перечислены
некоторые критические факторы бессерверной архитектуры для системы уведомлений.
y Детализированная структура функции: разбейте логику приложения на
небольшие обособленные функции. Каждая функция должна решать конкретную задачу или обрабатывать конкретное событие. Такая детализация
обеспечивает эффективное использование ресурсов и улучшает масштабируемость. У вас могут быть отдельные функции для отправки лайков,
комментариев и запросов на добавление в друзья.
y Отсутствие состояния: бессерверные функции проектируются так, чтобы
не сохранять состояния. Все управление необходимым состоянием должно
осуществляться извне (например, в базе данных или в сервисе хранения
данных). Тем самым гарантируется, что функции смогут масштабироваться
и их можно будет легко заменять без последствий для поведения приложения. Убедитесь, что каждая функция не хранит состояния и не зависит
от локальной памяти. Все необходимые данные (например, предпочтения
пользователей или история уведомлений) должны храниться в базе данных.
y Событийное проектирование: бессерверная архитектура хорошо подходит для приложений, управляемых событиями. Проектируйте функции
так, чтобы они срабатывали в ответ на определенные события: действия
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Бессерверная архитектура
203
пользователей и изменения данных. Например, когда пользователь получает
новый запрос на добавление в друзья, событие может вызвать соответствующую функцию.
«Холодный старт»: бессерверные функции могут сталкиваться с задержкой
при первом вызове (так называемый холодный старт). Это может задержать
доставку уведомлений, поэтому архитектура должна быть спроектирована
так, чтобы минимизировать влияние «холодных стартов» — например, с использованием выделенного параллелизма для поддержания определенного
количества экземпляров функции в «теплом» состоянии, готовом к обработке
входящих запросов.
Масштабируемость: бессерверные платформы автоматически масштабируют
функции в зависимости от спроса. Это позволяет приложению обрабатывать неожиданные выбросы трафика без ручного вмешательства. С ростом
пользовательской активности система будет обрабатывать таким способом
большее количество уведомлений.
Факторы производительности: следует понимать ограничения бессерверных платформ — например, времени выполнения и памяти. Оптимизируйте
функции для производительности, чтобы система уведомлений быстро реагировала даже в периоды повышенного трафика.
Распределенная трассировка и мониторинг: реализуйте мониторинг и распределенную трассировку, чтобы получать информацию о производительности бессерверных функций. Она будет критична для выявления «узких
мест» и диагностики проблем при доставке уведомлений.
Безопасность: реализуйте лучшие практики безопасности для бессерверных
архитектур, чтобы предотвратить несанкционированный доступ к уведомлениям. К этой категории относятся аутентификация, авторизация и шифрование данных при хранении и передаче.
Управление затратами: хотя бессерверные решения могут быть экономически
эффективными, очень важно организовать мониторинг использования и затрат. Настройте сигналы о превышении бюджета и воспользуйтесь средствами
поставщика для анализа расходов. С бессерверными решениями вы платите
за время выполнения, поэтому оптимизируйте код для его сокращения и рассмотрите возможность применения средств анализа затрат для мониторинга
использования.
Хранение данных: выберите подходящие варианты хранения данных (например, управляемая база данных, хранилище объектов или хранилище данных).
Обеспечьте сохранение данных при вызовах функций. В системе из нашего
примера пользовательские предпочтения и история уведомлений будут
храниться в управляемой базе данных, обеспечивая согласование данных
между вызовами функций.
Зависимости: помните о зависимостях функций. Включение лишних биб
лиотек или компонентов может увеличить размер развертываемого пакета
204
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
y
y
y
и повлиять на производительность. Минимизируйте зависимости, чтобы
пакет развертывания функции был компактным и эффективным.
y Тестирование и отладка: разработайте эффективные стратегии тестирования
для бессерверных функций. Используйте локальные эмуляторы и средства
отладки, предоставленные облачным провайдером.
y Использование управляемых сервисов: термин «бессерверный» не означает,
что каждый компонент должен быть функцией. Используйте управляемые
сервисы для других частей архитектуры приложения: баз данных, очередей
и аутентификации.
y Комплаенс и регулирование: учитывайте все требования соответствия стандартам или нормам, которые применяются к вашему приложению, особенно
при работе с чувствительными данными или в отраслях со строгим законодательством. Убедитесь, что архитектура соответствует нормам защиты
данных, особенно при обработке персональной информации.
Тщательно учитывая эти факторы, можно создать четко спроектированные бессерверные приложения, которые получают преимущества автомасштабирования,
экономии и упрощенного управления. Бессерверная архитектура обеспечивает
масштабируемость, экономическую эффективность и быструю доставку уведомлений без отвлечения ресурсов на управление инфраструктурой.
При разработке бессерверной архитектуры отсутствие состояния играет ключевую роль. Проектируя приложения без сохранения состояния, вы сокращаете
зависимость от состояний сессий под управлением сервера, что, в свою очередь,
улучшает масштабируемость. Архитектура без сохранения состояния чрезвычайно важна для масштабирования облачно-ориентированных архитектур.
Рассмотрим эту тему более подробно.
Дизайн архитектуры с сохранением
и без сохранения состояния
Архитектурные паттерны с сохранением и без сохранения состояния представляют два разных подхода к управлению взаимодействиями «клиент — сервер»
в приложениях. Архитектуры без сохранения состояния (stateless) рассматривают каждый запрос от клиента как отдельную независимую транзакцию, не
требующую знания предыдущих транзакций. Такой подход упрощает проектирование и улучшает масштабируемость, так как любой сервер может реагировать
на любой запрос без необходимости поддерживать информацию сессии. В свою
очередь, архитектуры с сохранением состояния (stateful) хранят сессионную
информацию клиента между запросами. Взаимодействия становятся более
персонализированными и контекстными, но это происходит за счет повышения
сложности при управлении данными сессий и проблемами с масштабированием,
так как состояние должно быть согласованным и синхронизированным между
экземплярами серверов.
Дизайн архитектуры с сохранением и без сохранения состояния
205
При проектировании сложных приложений (например, сайтов интернет-магазинов) необходимо обрабатывать состояние приложения для поддержания потока
активности, в котором пользователи могут выполнять цепочки операций (добавление товара в корзину, оформление заказа, выбор метода доставки, оплата).
Пользователи могут использовать разные каналы для обращения к приложению
и с высокой вероятностью будут переключаться между устройствами — например, добавлять товары в корзину с мобильного устройства, а затем завершать
оформление и проводить оплату с ноутбука. В такой ситуации необходимо
сохранять пользовательскую активность между устройствами и поддерживать
состояние пользователя до завершения транзакции. Таким образом, для выполнения этого требования в архитектуре и реализации приложения должно
быть запланировано управление пользовательскими сессиями.
Чтобы убрать состояние из приложений, информацию пользовательских сессий необходимо сохранять на уровне базы данных (например, в базе данных
NoSQL). Состояние представления может совместно использоваться разными
веб-серверами или микросервисами.
Традиционно монолитное приложение использует архитектуру с сохранением
состояния, при этом информация пользовательской сессии хранится на сервере,
а не во внешней базе данных.
Ключевое отличие архитектур без сохранения и с сохранением состояния проявляется в подходе к хранению данных сессий. В приложениях с сохранением состояния
сессионная информация хранится локально на сервере, что означает, что она не
может легко использоваться совместно с другими серверами. Эта конфигурация
создает проблемы с масштабируемостью и плохо подходит для современных микросервисных архитектур, так как требует, чтобы все последующие запросы от того
же пользователя маршрутизировались к исходному серверу, который обработал
первый запрос. Это может значительно ограничить способность приложения
масштабироваться по нескольким серверам или экземплярам.
Архитектуры без сохранения состояния не хранят сессионные данные на сервере,
позволяя любому серверу обработать любой запрос, который улучшает масштабируемость и гибкость. Выбор между принятием подхода с сохранением или
без сохранения состояния зависит от требований приложения, а именно того,
как оно выдерживает баланс необходимости масштабирования с потребностью
непрерывных персонализированных пользовательских взаимодействий.
Архитектура с сохранением состояния
В приложении с сохранением состояния информацию о состоянии обрабатывает
сервер, так что, когда пользователь создает соединение с конкретным сервером,
ему придется работать с этим сервером, пока транзакция не завершится. Можно
установить балансировщик нагрузки перед приложением с сохранением состояния, но для этого необходимо активировать закрепленные (sticky) сессии
в балансировщике нагрузки.
206
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Закрепленные сессии — метод, используемый для направления всех запросов от
конкретного пользователя на сервер, который обработал исходный запрос. Этот
метод необходим в приложениях с сохранением состояния для обеспечения согласованности сессий, так как он предотвращает потерю сессионных данных при
направлении последующих запросов другим серверам. При использовании закреп
ленных сессий балансировщик нагрузки отклоняется от стандартной практики
равномерного распределения запросов между серверами, обычно осуществляемого
по циклическому принципу, а вместо этого направляет запросы пользователя конкретному серверу, на котором хранится информация его сессии. Хотя этот метод
поддерживает долгосрочные сессии, он создает определенные проблемы — например, опасность перегрузки одного сервера из-за слишком большого количества
одновременных подключений. Чтобы этого избежать, важно реализовать механизм
тайм-аута сессий, чтобы они не поглощали ресурсы сервера до бесконечности.
Часто приложение с сохранением состояния не поддерживает горизонтальное
масштабирование в должной мере, так как состояние приложения хранится на
сервере, который невозможно заменить. Приложение с сохранением состояния
очень хорошо работает при небольшой базе данных. Тем не менее с распространением интернета логично, что веб-приложение сможет иметь миллионы активных
пользователей. Следовательно, эффективное горизонтальное масштабирование
играет важную роль для обслуживания большой пользовательской базы и обес
печения низкой задержки приложения.
Архитектура без сохранения состояния
Если вы используете подход без сохранения состояния, ваш дизайн должен
быть в большей степени ориентирован на общее состояние сессии, так как оно
допускает горизонтальное масштабирование.
На рис. 5.2 изображена архитектура приложения без сохранения состояния для
веб-приложения на базе AWS.
Эта архитектура AWS предоставляет защищенную масштабируемую среду
с высокой доступностью для трехуровневого приложения между двумя зонами
доступности. Она использует балансировщик нагрузки Elastic Load Balancer
для распределения трафика между двумя кластерами серверов EC2, которые
динамически масштабируются механизмом Auto Scaling в соответствии с изменяющимися потребностями. Уровень базы данных, в основе которого лежит
Amazon RDS, включает реплику для чтения для масштабирования запросов
и резервный экземпляр для обработки отказов, обеспечивающий надежность
данных и высокую доступность.
Статический контент предоставляется Amazon S3 и эффективно доставляется
через Amazon CloudFront, при этом AWS Route 53 управляет сервисами DNS
для оптимизации маршрутизации пользовательского трафика. Такая конфигурация обеспечивает операционную устойчивость, экономическую эффективность
Дизайн архитектуры с сохранением и без сохранения состояния
207
и оптимизацию производительности для приложения. Чтобы приложения были
слабосвязанными и масштабируемыми, все пользовательские сессии хранятся
в базе данных NoSQL — например, Amazon DynamoDB.
Route 53
Облако AWS
Зона доступности 1
Amazon S3
Зона доступности 2
Балансировщик нагрузки Elastic Load Balancer
VPC
Группа Auto
Scaling
Кластер серверов Amazon EC2
Веб-уровень
Кластер серверов Amazon EC2
Группа Auto Scaling
Уровень приложения
Реплика
Amazon RDS экземпляра БД,
предназначенная
для чтения
Уровень базы данных
Кластер серверов Amazon EC2
Кластер серверов Amazon EC2
Amazon
CloudFront
Резервный
Реплика
экземпляра БД, экземпляр базы
данных
предназначенная
для чтения
Рис. 5.2. Архитектура приложения без сохранения состояния
Для идентификатора сессии следует использовать хранилище на стороне клиента — например, данные cookie. Такая архитектура позволяет масштабировать
приложение горизонтально путем добавления новых серверов, не беспокоясь
о потере информации пользовательского состояния. Архитектура без сохранения
состояния избавляет от затрат на создание и обслуживание пользовательских
сессий и обеспечивает согласованность между модулями приложения. Кроме
того, приложение без сохранения состояния выигрывает в производительности,
так как оно сокращает затраты памяти на стороне сервера и исключает проблему
с тайм-аутом сессии.
Реализация архитектуры без сохранения состояния подразумевает такие сложности, как интеграция дополнительных компонентов базы данных для хранения
пользовательских сессий и создание вспомогательного уровня для передачи
актуального состояния пользователя между серверами. Тем не менее при правильном подходе результат произведет хорошее впечатление на пользователей.
Можно разрабатывать приложения с использованием микросервисного подхода
с паттернами проектирования REST и развертывать их в контейнерах. Для этого
при подключении пользователей к серверам следует применять аутентификацию
и авторизацию.
В следующих разделах вы больше узнаете о микросервисах и паттернах проектирования REST. Так как обращения к информации пользовательской сессии
от нескольких веб-серверов обслуживаются одним хранилищем данных, необходимо действовать осмотрительно, чтобы производительность хранилища
данных не стала «узким местом» системы.
208
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Микросервисная архитектура
В облачно-ориентированных архитектурах микросервисы играют важную роль
в разбиении обширной функциональности на меньшие, более удобные блоки,
которые могут масштабироваться независимо. Такой подход позволяет масштабировать отдельные компоненты по мере необходимости, не влияя на систему
в целом. При использовании микросервисов система проектируется как отказоустойчивая. Это означает, что она строится с учетом потенциальных сбоев, что
подразумевает щадящее снижение доступности приложения и предотвращение
широкого распространения отказов уровня всей системы.
Очевидное преимущество микросервисов — необходимость поддерживать меньший объем кода. Микросервисы всегда должны быть независимыми. Каждый
сервис строится без внешних зависимостей, что сокращает взаимные зависимости
между модулями приложения и способствует слабой связанности.
y
y
y
Другая обобщающая концепция микросервисов — ограниченные контексты
(bounded context), то есть блоки, объединяемые для формирования предметной
области бизнеса. Предметной областью бизнеса может быть розничная торговля,
производство автомобилей, продажа книг или социальные взаимодействия, включающие полные бизнес-процессы. Отдельный микросервис определяет границы,
по которым инкапсулируются все детали. Для примера рассмотрим платформу
интернет-магазина. В такой системе задействованы несколько микросервисов,
обрабатывающих разные бизнес-операции или бизнес-области. Несколько примеров ограниченных контекстов на такой платформе.
y Контекст учетных записей пользователей: микросервис обрабатывает все,
что связано с учетными записями пользователей, включая регистрацию,
управление профилями, вход и аутентификацию. Границы контекста охватывают информацию о пользователях и операции, которые могут выполняться
с этими данными, — например, обновление профиля или сброс пароля. Никакой другой микросервис не управляет этими операциями.
y Контекст каталога товаров: микросервис отвечает за управление перечнем
товаров, категорий и подробными описаниями товаров. Он работает независимо от контекста учетных записей пользователей, концентрируясь исключительно на товарах, их организации и отображении для пользователей.
y Контекст обработки заказов: микросервис обеспечивает процесс оформления заказов, отслеживание заказов и обработку платежей. Он использует
информацию из контекста каталога товаров (идентификаторы товаров, цены
и т. д.) и контекста учетных записей пользователей (например, подробную
информацию о клиенте) для выполнения своих функций, но при этом поддерживает собственные операции — например, обновление статуса заказа
или обработку возврата товаров.
Каждый ограниченный контекст представляет собой автономную систему с собственной логикой предметной области и базой данных, которая взаимодействует
Микросервисная архитектура
209
с другими системами через четко определенные API. Эти границы позволяют
разрабатывать, развертывать, масштабировать и обновлять каждый микросервис
независимо от других, делая систему в целом более устойчивой и способной
адаптироваться к изменениям.
Установление подобных границ на платформе интернет-магазина гарантирует, что изменения в одном контексте (например, добавление новых способов
оплаты в контексте обработки заказов) не повлияют на контексты учетных
записей пользователей или каталогов товаров. Это упрощает обслуживание
и масштабирование системы.
Масштабирование каждого сервиса критически важно при работе с высоконагруженными приложениями, когда разные рабочие нагрузки имеют разные
требования к масштабированию.
y
y
y
y
y
Рассмотрим некоторые лучшие практики проектирования микросервисных
архитектур.
y Создание отдельного хранилища данных: команда может выбрать в качестве
хранилища базу данных, которая лучше всего подходит для их микросервиса.
Например, команда, занимающаяся трафиком веб-сайта, может использовать
масштабируемую базу данных NoSQL для хранения полуструктурированных
данных. Команда, занимающаяся обработкой заказов, может выбрать реляционную базу данных для обеспечения целостности данных и согласованности
транзакций. Кроме того, такая схема поможет достичь слабой связанности,
чтобы изменения в одной базе данных не влияли на работу других сервисов.
y Серверы без сохранения состояния: как вы узнали из предыдущего раздела,
«Дизайн архитектуры с сохранением и без сохранения состояния», если
состояние не хранится на сервере, это упрощает масштабирование. Сервер,
вышедший из строя, должно быть легко заменить, а для этого нужно, чтобы
он хранил минимальное состояние (или вообще никакого).
y Создание отдельной сборки: создание отдельной сборки для каждого микросервиса упрощает для команды разработки внесение изменений и делает процесс выпуска новых версий более адаптивным. При таком подходе команда
разработки пишет код только для конкретного микросервиса и не влияет на
другие сервисы.
Развертывание
в контейнере: эта практика позволяет развертывать все
y
компоненты одним стандартным способом. При использовании контейнеров
можно одинаково развертывать все микросервисы независимо от их природы.
Чтобы управлять контейнером, не заботясь об инфраструктуре, можно воспользоваться сервисами бессерверного развертывания контейнеров — такими,
как Amazon Fargate.
y Бессерверный подход: рекомендуется пользоваться бессерверной платформой или вспомогательной функцией с возможностями сервиса (например,
AWS Lambda), если микросервисы достаточно просты. Бессерверная архитектура помогает избежать накладных расходов на управление инфраструктурой.
210
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
y
y Сине-зеленое развертывание: для развертывания приложения лучше всего
y
создать копию рабочей среды. Разверните там новую функциональность
и маршрутизируйте небольшой процент пользовательского трафика, чтобы
убедиться, что новая функциональность в новой среде работает как было
задумано. После этого увеличивайте трафик, пока новая функциональность не будет доступна всем пользователям. Вы больше узнаете о синезеленом развертывании в главе 11 «DevOps и фреймворк архитектуры
решений».
y Мониторинг среды: хороший мониторинг позволяет перейти от реакции на
сбои к их активному предотвращению за счет изменения маршрутизации,
масштабирования и управляемого снижения функциональности. Если вы
хотите предотвратить простои приложения, сервисы должны предоставлять
и отправлять информацию о своей работоспособности уровню мониторинга.
В конце концов, кто лучше знает статус сервиса, чем сам сервис? Мониторинг
можно осуществлять многими способами — например, с использованием
плагинов или посредством записи через 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 по экономичной бессерверной схеме.
Эта архитектура не только базируется на микросервисах, но и является бессерверной. Используя микросервисы, можно создавать приложения из небольших
независимых компонентов. Применение микросервисной архитектуры означает
снижение затрат, размеров и риска изменений, что повышает скорость изменений.
AWS Lambda записывает сумму голосов
в другую таблицу Amazon DynamoDB
DynamoDB сохраняет голоса
с поддержкой DynamoDB Streams,
которая отслеживает
изменения в таблицах
Отправляется контент
сообщения
Пользователи
отправляют свои
голоса по телефону
в виде сообщения
Функция Lambda
извлекает голос
из сообщения
и сохраняет его
Сохранение
суммы
голосов
Сохранение
каждого
голоса
Route S3 предоставляет адрес
веб-сайта и обеспечивает
маршрутизацию к веб-странице
Amazon S3 размещает веб-сайт
и данные запроса в Amazon DynamoDB
для отображения итогового дашборда
Пользователь запрашивает
окончательный результат голосования
Рис. 5.3. Приложение для голосования в реальном времени
на базе микросервисов с AWS
212
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
В распределенных системах с использованием микросервисов важна координация между несколькими сервисами. В следующем разделе вы узнаете, как
координировать работу нескольких микросервисов.
Паттерн Saga (Сага)
«Сага» — паттерн проектирования, используемый для управления продолжительными сложными бизнес-транзакциями. Этот паттерн особенно полезен
в микросервисных архитектурах, когда в одной бизнес-транзакции может быть
задействовано несколько микросервисов. Вместо традиционного двухфазного
коммита паттерн «Сага» делит транзакцию на несколько меньших изолированных транзакций. Каждая из меньших транзакций обрабатывается отдельными
сервисами, работа которых координируется для обеспечения согласованности
данных между ними. Если в одной из меньших транзакций происходит сбой,
выполняются компенсирующие транзакции для отмены предыдущих шагов.
В сложных системах, в которых несколько сервисов должны работать совместно
для выполнения одной операции (например, обработки заказа или бронирования
билета), паттерн «Сага» гарантирует, что, если в какой-то момент что-то пойдет
не так, вся операция будет либо полностью завершена, либо отменена.
y
y
y
y
y
Схема работы паттерна «Сага»:
y декомпозиция: операция, которую необходимо выполнить, разбивается на
меньшие изолированные шаги или транзакции. Каждый шаг соответствует
действию, выполняемому конкретным микросервисом;
y компенсирующие действия: для каждого шага определяется соответствующее компенсирующее действие. Если при выполнении шага происходит сбой
или ошибка, выполняется компенсирующее действие, отменяющее эффекты
предыдущих шагов. Таким образом система возвращается в согласованное
состояние;
y координатор: отвечает за оркестрацию последовательности действий и соответствующих компенсирующих действий. Он инициирует запуск «Саги»,
отслеживает ее прогресс и определяет, были ли завершены все шаги, или
предпринимает необходимые компенсирующие действия;
y локальные транзакции: каждый шаг и его компенсирующие действия инкапсулируются в локальной транзакции с соответствующими микросервисами.
Таким образом обеспечивается атомарность операций в каждом микросервисе;
y согласованность в конечном счете: паттерн «Сага» поддерживает согласованность в конечном счете; это означает, что даже при возникновении
сбоя система со временем достигнет согласованного состояния благодаря
либо успешному завершению всей операции, либо откату в согласованное
состояние.
Рассмотрим для примера интернет-магазин, в котором клиент размещает заказ.
Паттерн «Сага» может использоваться для отработки всей процедуры обработки
заказов.
Микросервисная архитектура
213
1. Запуск: сервис заказа начинает новую сагу для обработки заказов.
2. Шаги: сага включает несколько шагов, выполняемых разными микросервисами, — например, проверку доступности товара, оплату заказа, обновление
запасов и оповещение клиента.
3. Компенсирующие действия: определяются соответствующие компенсирующие действия. Например, если товар отсутствует на складе: отмена оплаты,
пополнение запасов и отправка клиенту сообщения с извинениями.
4. Координатор: координатор осуществляет надзор над сагой, проверяя, что
каждый шаг был успешно выполнен или компенсирован. Например, координироваться может последовательность шагов от проверки наличия товара до
размещения заказа, взимания платы с клиента и передачи заказа на доставку.
5. Согласованность в конечном счете: если в любой момент произойдет сбой
(например, если попытка списания средств окажется неудачной), инициируются компенсирующие действия, которые должны вернуть систему в согласованное состояние.
Каждый сервис, задействованный в паттерне «Сага», генерирует и прослушивает
события, как показано на рис. 5.4.
Сервис заказов
Сервер запасов
Сервис платежей
Сервис доставки
Получает запрос на создание заказа
Состояние заказа — «в процессе обработки»
Публикует событие «OrderCreated»
Обрабатывает платеж
Публикует событие «PaymentProcessed»
Публикует событие «PaymentProcessed»
Проверяет и резервирует товары на складе
Публикует событие «StockReserved»
Публикует событие «StockReserved»
Планирует доставку
Публикует событие «ShipmentScheduled»
Публикует событие
«ShipmentScheduled»
Обновляет заказ статусом «завершен»
Сервис заказов
Сервис платежей
Сервер запасов
Сервис доставки
Рис. 5.4. Диаграмма последовательности действий паттерна «Сага»
в архитектуре интернет-магазина
214
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Как показано на рис. 5.4, когда сервис завершает свою часть транзакции, он
генерирует событие, которое инициирует следующий сервис в саге.
1. Сервис заказов получает запрос на создание заказа.
2. Сервис заказов запускает сагу, создавая заказ в состоянии обработки и пуб
ликуя событие OrderCreated (заказ создан).
3. Сервис платежей прослушивает событие OrderCreated, обрабатывает платеж
и публикует событие PaymentProcessed (платеж обработан).
4. Сервис запасов прослушивает событие PaymentProcessed, проверяет, что
товары присутствуют на складе, резервирует их и публикует событие StockReserved (товар на складе зарезервирован).
5. Сервис доставки прослушивает событие StockReserved, планирует доставку
и публикует событие ShipmentScheduled (отгрузка запланирована).
6. Сервис заказов прослушивает событие ShipmentScheduled и обновляет заказ,
переводя его в статус завершенного.
Если какой-либо из сервисов не может завершить свою часть транзакции, он
публикует компенсирующее событие, чтобы инициировать откат предыдущих
шагов. Например, если сервис запасов обнаруживает, что запас товара недостаточен, он может опубликовать событие StockInsufficient (товара на складе недостаточно). Сервис платежей прослушивает это событие и инициирует возврат
платежа. Сервис заказов прослушивает событие StockInsufficient и обновляет
заказ, переводя его в статус отмененного.
Паттерн «Сага» — вариант дизайна, который решает проблему согласованности
данных в распределенных системах, особенно при работе с микросервисами.
Вместо того чтобы использовать одну крупномасштабную транзакцию для обес
печения согласованности данных между разными сервисами, паттерн «Сага»
разбивает транзакцию на серию локальных транзакций для каждого сервиса.
Каждая локальная транзакция обновляет базу данных и публикует событие или
сообщение, которое является признаком успеха или неудачи транзакции. С другой стороны, паттерн «Сага» вводит концепцию согласованности в конечном
счете; это означает, что состояние системы станет согласованным со временем,
но не обязательно немедленно. Кроме того, реализация паттерна «Сага» может
оказаться сложной, так как для него придется обрабатывать сценарии отказов
и следить за тем, чтобы компенсирующие действия правильно отменяли предыдущие операции. Часто это требует сложной координации и надежных систем
передачи сообщений для управления асинхронными коммуникациями между
сервисами.
Паттерн «Сага» позволяет разбивать сложные операции на простые шаги, с защитными мерами для обработки отказов и обеспечения целостности данных.
Паттерн улучшает устойчивость в распределенных системах, гарантируя, что
система будет обладать связностью и согласованностью в конечном счете даже
при возникновении сбоев. Тем не менее реализация паттерна «Сага» требует
Микросервисная архитектура
215
тщательного проектирования и координации для эффективной обработки
различных сценариев отказов. Что, если у вас имеется обширная информация,
которая должна быть обработана разными микросервисами, но при этом консолидирована для формирования значимой аналитики? В таких сценариях на
помощь приходит паттерн Fan-out/Fan-in. В следующем разделе он рассматривается более подробно.
Паттерн Fan-out/Fan-in (Разветвление/схождение)
Паттерн проектирования Fan-out/Fan-in («Веерное распределение/сбор» или
«Разветвление/схождение») часто применяется в распределенных системах
для эффективной обработки запросов и агрегирования данных от нескольких
источников. Он полезен в сценариях, требующих сбора, обработки и консолидации данных от разных входящих потоков или источников. Паттерн получил
свое название по тому, как данные разветвляются (Fan-out) на несколько источников, а затем сходятся (Fan-in) обратно для агрегирования.
y
y
Возьмем систему аналитики в реальном времени для платформы социальной
сети. Паттерн Fan-out/Fan-in может быть применен для сбора и обработки
данных по разным пользовательским активностям. Посмотрим, как он работает.
y Фаза разветвления (fan-out):
в фазе разветвления данные собираются из различных источников, включая различные микросервисы, API и потоки данных. Каждый источник
отправляет свои данные отдельному обрабатывающему компоненту.
Пользовательские посты, комментарии, лайки, публикации и подписчики
генерируют потоки данных реального времени;
обработчики всех источников работают независимо от других и одновременно. Это позволяет организовать эффективную параллельную обработку, сокращая время сбора данных от разных источников. С каждым
видом активности связан выделенный обработчик, который вычисляет
различную статистику: коэффициент вовлеченности, популярный контент,
популярные темы и т. д.
Фаза
схождения (fan-in): после завершения раздельной обработки резульy
таты всех обработчиков агрегируются (в данном примере — для вычисления
общих метрик вовлеченности платформы). Агрегирование может включать
вычисление, суммирование или любые другие операции, необходимые для
получения конечного результата. Из агрегированных данных генерируется
желаемый результат или итоговый отчет. Это может быть простой отчет, сводный анализ или любая другая разновидность консолидированных данных.
В нашем примере данные отображаются для администраторов в виде дашборда, на котором в реальном времени выводятся аналитические показатели.
В рассмотренном примере паттерн Fan-out/Fan-in позволяет аналитической
системе эффективно обрабатывать и консолидировать данные по разным
216
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
пользовательским активностям, предоставляя администраторам аналитику
вовлеченности пользователей в реальном времени.
Преимущества паттерна Fan-out/Fan-in
y
y
y
y
Паттерн Fan-out/Fan-in определяет стратегический подход в распределенных
системах, значительно улучшающий обработку и управление данными. Ключевые преимущества этого паттерна:
y параллелизм: паттерн делает возможной параллельную обработку, ускоряя
сбор и агрегирование данных из нескольких источников;
y эффективность: вместо последовательной обработки данных от каждого
источника паттерн оптимизирует время обработки за счет одновременной
работы с несколькими источниками;
y масштабируемость: каждый источник может обрабатываться независимо
от других, что позволяет эффективно масштабировать систему с ростом
количества источников;
y модульность: паттерн, способствует модульности архитектур за счет отделения фазы сбора данных (разветвления) от агрегирования (схождение). Такое
разделение упрощает обслуживание и расширение системы.
Хотя паттерн 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. EC2 сервис А представляет экземпляр Amazon EC2, на котором работает
сервис (Сервис А). Экземпляры EC2 представляют масштабируемые вычислительные мощности в облаке AWS (Amazon Web Services).
2. Вызывает сервис B: сервис A инициирует вызов к сервису B. В этой точке
начинается процесс межсервисного взаимодействия.
3. Коммуникации: этот блок представляет уровень коммуникаций, на котором
запрос сервиса A перехватывается для маршрутизации через сетку сервисов.
4. Через App Mesh: запрос от сервиса A проходит через AWS App Mesh — сервисную сетку, предоставляющую сетевые взаимодействия уровня приложения. App Mesh стандартизирует коммуникации между сервисами, обеспечивая
сквозную видимость и высокую доступность для приложений.
218
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
5. Маршрутизируется к сервису B: AWS App Mesh маршрутизирует запрос
к соответствующему сервису (в данном примере это сервис B).
6. ECS сервис B: представляет задачу Amazon ECS (Elastic Container Service).
ECS — высокомасштабируемый, высокопроизводительный сервис управления контейнерами, поддерживающий контейнеры Docker.
7. Вызывает сервис C: после того как сервис B завершит свою обработку, он
вызывает сервис C. Этот вызов может быть частью большей транзакции,
включающей несколько микросервисов.
8. Маршрутизируется к сервису C: AWS App Mesh снова маршрутизирует
вызов от сервиса B к сервису C.
9. Lambda сервис C: представляет функцию AWS Lambda для сервиса C. AWS
Lambda позволяет выполнить код без выделения серверов или управления
серверами. Код выполняется только тогда, когда это необходимо, а схема
масштабируется автоматически.
Архитектура абстрагирует сложные взаимодействия сервисов в сервисной сетке,
демонстрируя роль AWS App Mesh в управлении, маршрутизации и контроле
коммуникаций между разными сервисами.
Сервисы приложения
EC2 сервис А
1. Вызывает сервис B
Коммуникации
Коммуникации
2. Через App Mesh
Сервисная сетка
AWS App Mesh
3. Маршрутизируется
к сервису B
4. Вызывает сервис C
EC2 сервис B
5. Маршрутизируется к сервису C
Lambda сервис C
Рис. 5.5. Архитектурный паттерн Service mesh (cервисная сетка)
в облаке AWS
Микросервисная архитектура
219
y
y
y
y
y
Перечислим основные возможности, предоставляемые сервисной сеткой.
y Управление трафиком: предоставляет детализированный контроль над поведением трафика с подробными правилами маршрутизации, повторными
попытками, обработкой отказов и внедрением сбоев.
y Наблюдаемость: обеспечивает более глубокое понимание приложений
благодаря визуализации, трассировке, мониторингу и регистрации трафика
между сервисами.
y Безопасность: предоставляет автоматизированное взаимное шифрование
трафика TLS (mTLS) между сервисами.
y Соблюдение политик: позволяет определять и устанавливать политики для
всех сервисов независимо от того, где они работают.
y Устойчивость: делает возможной расширенную балансировку нагрузки, таймауты и повторные попытки, помогая создавать более устойчивые приложения.
Популярный способ реализации сервисной сетки основан на использовании
вспомогательных прокси-серверов. Каждый экземпляр сервиса в микросервисном приложении дополняется вспомогательным прокси-сервером, который
обеспечивает все сетевые коммуникации к сервису и от него. Все эти проксисерверы соединяются между собой, образуя сетку, отсюда и название service
mesh (англ. mesh — сетка, переплетение).
y
y
Сервисные сетки становятся неотъемлемой частью современных облачно-ориентированных архитектур приложений. Они предоставляют разнообразные
реализации, адаптированные для разных потребностей и сред. Самые популярные
реализации сервисных сеток следующие.
y Istio: это комплексное решение предоставляет надежный механизм управления межсервисными коммуникациями в микросервисной архитектуре.
Оно позволяет разработчикам задавать подробные правила маршрутизации
и политики, реализовывать паттерны устойчивости (такие, как повторные
попытки и переключатели), а также собирать аналитические данные о потоках трафика приложения. Возможности Istio по соблюдению политик
и сбору метрик помогают повысить уровень защиты и вести наблюдение за
коммуникациями между сервисами, таким образом повышая надежность
и производительность сети.
y Linkerd: пользуется популярностью благодаря своей простоте и производительности. Linkerd — сервисная сеть с открытым исходным кодом,
предоставляющая такие важные функции, как обнаружение сервисов,
маршрутизация, обработка отказов и видимость для инфраструктур современных приложений. Система проектировалась с расчетом на легковесность, простоту установки и минимальный след в системе, что делает ее
привлекательной для команд, желающих перейти на технологию сервисных
сеток без значительных затрат.
220
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
y
y AWS App Mesh: система, спроектированная специально для пользователей
y
AWS, представляет собой управляемый сервис, упрощающий управление
и контроль над коммуникациями между микросервисами в среде сервисов
AWS. App Mesh поддерживает сетевые взаимодействия уровня приложения, что позволяет приложениям взаимодействовать по сети с большей
видимостью и контролем. AWS App Mesh упрощает конфигурацию сетевых
коммуникаций, предоставляя аналитические данные уровня приложения
и обеспечивая высокую доступность приложений.
y Consul Connect: Consil Connect (часть HashiCorp Consul) обеспечивает
межсервисные коммуникации с автоматическим шифрованием TLS и авторизации, основанной на идентификационных данных. Это платформеннонезависимое решение, предоставляющее согласованный, унифицированный
метод защиты и настройки коммуникаций между сервисами независимо от
используемой платформы. Consul Connect уделяет первоочередное внимание
безопасности и следит за тем, чтобы только авторизованные сервисы могли
взаимодействовать друг с другом, тем самым сокращая риск внутренних угроз.
Хотя сервисные сетки предоставляют целый ряд преимуществ для микросервисных
архитектур (такие, как улучшение межсервисных коммуникаций, повышение уровня безопасности и улучшенная наблюдаемость), необходимо учитывать сложность,
которую они добавляют в инфраструктуру. Внедрение сервисной сетки подразу
мевает добавление компонентов для управления, мониторинга и обслуживания,
что может повысить эксплуатационные затраты. Этот дополнительный уровень
инфраструктуры требует тщательного планирования, квалифицированных специа
листов для управления и четкого понимания его влияния на производительность
и сложность системы. Следовательно, прежде чем принимать решение о реализации
сервисной сетки, необходимо оценить специфические потребности приложения
и сравнить потенциальную выгоду с возможным повышением инфраструктурной
сложности. Такой осторожный подход гарантирует, что преимущества использования сервисной сетки будут соответствовать требованиям приложения и способности команды справиться с дополнительной сложностью.
Рассмотрим подробнее AWS App Mesh — инструмент, нормализующий коммуникации между сервисами и обеспечивающий всесторонний мониторинг и постоянную доступность. На рис. 5.6 представлена реализация паттерна Service
mesh с использованием облачных сервисов AWS.
Как показано на диаграмме, Amazon Fargate работает как бессерверный механизм для контейнерных вычислений, совместимый с Amazon ECS (Elastic
Container Service) и Amazon EKS (Amazon Elastic Kubernetes Service). Ниже
перечислены основные этапы реализации приложения интернет-магазина под
управлением App Mesh.
1. Создание сервисов Fargate: определение каждого микросервиса (пользователи, заказы, платежи, каталог товаров и аутентификация) как Amazon
Fargate в EKS с необходимыми формулировками задач.
Микросервисная архитектура
221
2. Создание AWS App Mesh: создание сетки, которая служит логической границей для сетевого трафика между сервисами.
3. Определение виртуальных узлов: создание виртуального узла для каждого
сервиса ECS в App Mesh. Виртуальный узел служит логическим указателем
на конкретный сервис ECS.
4. Создание виртуальных маршрутизаторов и маршрутов: определение виртуальных маршрутизаторов и маршрутов для управления потоком трафика
между виртуальными узлами.
5. Конфигурация виртуальных сервисов: виртуальные сервисы маршрутизируют трафик к виртуальным узлам, делая возможным обнаружение сервисов
в сетке.
6. Развертывание вспомогательных прокси-серверов: присоединение прокси-сервер Envoy к определению каждой задачи ECS как вспомогательного
контейнера. Прокси-серверы Envoy перехватывают трафик между микросервисами и управляют им.
7. Мониторинг и ведение журнала: использование AWS CloudWatch и AWS
X-Ray для мониторинга и ведения журнала трафика, проходящего через сетку.
Облако AWS
Обнаружение
контейнеров
VPC
AWS App Mesh
Область данных
AWS Cloud Map
VPC
AWS
Fargate
Проксисервер
Микросервис
каталога товаров
AWS X-Ray
AWS
Fargate
Проксисервер
Микросервис заказов
AWS Identity and Access Management (IAM)
AWS
Fargate
Проксисервер
Микросервис корзины
Amazon CloudWalch
AWS
Fargate
Область
управления
Проксисервер
Микросервис запасов
AWS CloudTrail
Рис. 5.6. Приложение интернет-магазина под управлением App Mesh в AWS
Реализация сервисной сетки может улучшить межсервисные коммуникации, безопасность и наблюдаемость. Этот подход позволяет более эффективно управлять
микросервисной архитектурой, обеспечивая надежность и масштабируемость
222
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
сложных приложений. Восстановление после сбоев — важное условие построе
ния крупномасштабных архитектур. Познакомимся поближе с реактивными
архитектурами, которые помогут в решении этой проблемы.
Реактивная архитектура
Поскольку облачная архитектура может иметь подвижные части из-за множества микросервисов и небольших модулей, их необходимо защищать от сбоев.
Реактивная архитектура — метод проектирования для построения продуктов,
которые могут эффективно справляться с изменениями и оставаться отзывчивыми в различных условиях. Она хорошо подходит для крупномасштабных
и распределенных систем, которые должны обеспечивать высокую доступность
и отзывчивость даже при возникновении сбоев или высокой нагрузке.
y
y
y
y
Принципы реактивной архитектуры базируются на Реактивном манифесте
(или Манифесте реактивных систем) — документе, описывающем основные
характеристики реактивных систем: отзывчивость, устойчивость, эластичность
и управление посредством обмена сообщениями. Подробнее о Реактивном манифесте можно узнать на сайте https://www.reactivemanifesto.org/.
y Отзывчивость: приоритетное свойство реактивных систем — быстрая реакция на запросы пользователя независимо от загруженности или состояния
системы.
y Устойчивость: реактивные системы проектируются с расчетом щадящей
обработки отказов. Они могут быстро восстанавливать работоспособность
и действовать даже при отказе некоторых компонентов.
y Эластичность: реактивные системы могут масштабироваться в зависимости
от потребностей, эффективно используя ресурсы и обеспечивая отзывчивость
при разных рабочих нагрузках.
y Обмен сообщениями: в реактивных системах компоненты взаимодействуют
с использованием асинхронно передаваемых сообщений. Такой подход делает
возможным слабую связанность компонентов, их независимую изоляцию
и доступность из разных местоположений.
Стиль реактивной архитектуры в значительной мере зависит от микросервисов,
которые сегментируют функциональность на меньшие, независимо масштабируемые системы для улучшения масштабируемости, удобства обслуживания
и ускорения циклов развертывания. Коммуникации в реактивных системах
управляются событиями. Это означает, что компоненты взаимодействуют
и реагируют при помощи асинхронных событий; таким образом обеспечивается
более эффективное использование ресурсов и повышается производительность
системы.
Для управления данными реактивные архитектуры применяют децентрализованный подход, когда каждый микросервис управляет своими данными, сокращая зависимости и конкуренцию за общие ресурсы. Тем самым повышается не
Реактивная архитектура
223
только устойчивость системы, но и ее способность быстро восстанавливаться
после сбоев. Изоляция и автономность занимают центральное место в реактивных системах. Они гарантируют, что отказ одних компонентов не повлияет на
работу других и доступность системы в целом, а это повышает отказоустойчивость системы.
Масштабируемость обеспечивается горизонтально, когда для обработки повышенной нагрузки система расширяется за счет добавления новых экземпляров
сервисов вместо увеличения мощности существующих экземпляров.
Кроме того, реактивные архитектуры реализуют различные паттерны устойчивости: переключатели, тайм-ауты и повторные попытки. Эти механизмы помогают
управлять сбоями и восстанавливаться после них, не позволяя проблемам одного
компонента распространиться на всю систему. Совместно эти принципы упрощают создание отказоустойчивых, отзывчивых систем, способных сокращать
свою функциональность под нагрузкой постепенно.
Реактивные архитектуры особенно полезны в крупномасштабных распределенных системах, которые должны справляться с разными нагрузками, быстро
восстанавливаться после сбоев и быстро реагировать на запросы пользователя.
y
y
y
y
y
y
Представьте игровую платформу, на которой тысячи игроков одновременно
взаимодействуют с виртуальными мирами. Применение реактивной архитектуры позволит обеспечить плавные игровые взаимодействия и быстрый отклик.
y Отзывчивость: система быстро реагирует на действия игроков, позволяя персонажам двигаться, кастовать (применять заклинания) и взаимодействовать
с объектами в реальном времени.
y Устойчивость: если сервер внезапно упадет по техническим причинам, архитектура автоматически перенаправит нагрузку на работоспособные серверы,
обеспечивая непрерывный геймплей для других игроков.
y Эластичность: по мере того как в пиковые периоды в игре участвует все больше игроков, архитектура динамически выделяет дополнительные серверные
ресурсы для обработки повышенной нагрузки. С уменьшением количества
игроков лишние ресурсы освобождаются для экономии затрат.
y Обмен сообщениями: действия игроков (кастование, покупка предметов
и т. д.) передаются через сообщения. Асинхронные коммуникации сводят
к минимуму «узкие места» и обеспечивают плавность геймплея, несмотря
на множество параллельно выполняемых действий.
Реализовать реактивную архитектуру можно по следующей схеме.
y Спроектировать компоненты для асинхронных взаимодействий с использованием очередей сообщений. Таким образом предотвращается блокирование
и улучшается быстрота реакции.
y Реализовать модель акторов, в которой компоненты (акторы) взаимодействуют посредством сообщений. Каждый актор обрабатывает сообщения
последовательно, избегая проблем с параллелизмом.
224
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
y
y Интегрировать паттерны устойчивости (такие, как «Предохранитель» (Circuit
y
y
Breaker) и «Переборка» (Bulkhead)) для обработки отказов и предотвращения каскадных ошибок. Эти паттерны были описаны в главе 4 «Паттерны
проектирования архитектур решений».
y Использовать механизмы автомасштабирования для динамического выделения ресурсов в зависимости от нагрузки. Облачные платформы (такие,
как AWS) предоставляют средства для этой цели.
y Использовать реактивные библиотеки или фреймворки (такие, как Akka,
Spring WebFlux или ReactiveX), предоставляющие абстракции для построе
ния реактивных систем.
Посмотрим, как реализовать реактивную архитектуру на базе сервисов AWS для
решения задачи трекинга рекламных взаимодействий. На рис. 5.7 изображена
реактивная архитектура для ad-tech компании1.
Сбор данных
Реестр контейнеров
Поглощение
данных
Балансировщик нагрузки AWS Fargate
приложения (ALB)
Lambda
Function
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Streams
Функция
Lambda
Amazon DynamoDB
Обновления
базовых данных
Рис. 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. Паттерны проектирования облачно-ориентированных архитектур
y
y
y
y
y
Познакомимся с терминологией архитектуры на базе очереди.
y Сообщение: состоит из двух частей — заголовка и тела. Заголовок содержит
метаданные, относящиеся к сообщению, а тело — собственно сообщение.
y Очередь: содержит сообщения, которые могут использоваться при необходимости.
y Производитель: сервис, производящий и публикующий сообщение в очереди.
y Потребитель: сервис, потребляющий сообщения.
y Брокер сообщений: помогает собирать, маршрутизировать и распределять
сообщения между производителем и потребителем.
Рассмотрим некоторые типичные архитектурные паттерны на базе очереди,
чтобы понять, как они работают.
Паттерн Queuing Chain (Цепочка очередей)
Паттерн «Цепочка очередей» применяется в ситуации, когда последовательная
обработка должна выполняться на нескольких связанных системах. Рассмотрим
его применение на примере приложения для обработки изображений. В пайплайне обработки графики последовательные операции — захват изображения,
сохранение его на сервере, запуск задания для создания копий изображения
в разном разрешении, нанесение водяных знаков и генерирование миниатюр —
тесно связаны друг с другом. Сбой в одной части может привести к нарушению
всей операции.
Можно использовать очереди между разными системами и заданиями, чтобы
устранить единую точку сбоя и спроектировать по-настоящему слабосвязанную систему. Паттерн «Цепочка очередей» позволяет связать разные системы
и увеличивает количество серверов, которые могут обрабатывать сообщения
параллельно. Чтобы завершить работу лишних серверов при отсутствии изображений для обработки, можно настроить автомасштабирование.
На рис. 5.8 показана архитектура паттерна «Цепочка очередей» для приложения
из рассматриваемого примера. Здесь очередь, предоставляемая AWS, называется
Amazon SQS (Simple Queue Service).
Изображенная архитектура включает следующие этапы.
1. Когда на сервер загружается необработанное изображение, приложение
должно пометить все изображения водяным знаком с логотипом компании.
Парк серверов Amazon EC2 (Elastic Cloud Compute) запускает пакетные задания для нанесения водяных знаков и помещает обработанное изображение
в очередь Amazon SQS.
2. Второй парк серверов Amazon EC2 загружает изображения с водяными
знаками из очереди Amazon SQS.
3. Второй парк воркеров EC2 обрабатывает изображение и создает его варианты
с разными разрешениями.
Архитектура на базе очереди
227
4. После кодирования изображений воркеры EC2 отправляют сообщение
в другую очередь Amazon SQL для создания миниатюр.
5. После обработки изображения задание удаляет сообщение из предыдущей
очереди для освобождения места.
6. Последний парк серверов EC2 получает закодированные сообщения из очереди и создает миниатюры вместе с метками авторского права.
Облако AWS
Обработка задания
3
EC2
EC2
EC2
4
Размещение
сообщения
1
Получение сообщения
Размещение
сообщения
Получение сообщения
6
2
5
Amazon
SQS
Удаление успешно
обработанного сообщения
Amazon
SQS
Сообщение в очереди
Рис. 5.8. Архитектура паттерна «Цепочка очередей»
y
y
y
Такая архитектура имеет следующие преимущества.
y Возможность использовать слабосвязанную асинхронную обработку, чтобы
быстро возвращать ответы, не ожидая подтверждения от другого сервиса.
y Систему можно структурировать слабым связыванием экземпляров Amazon
EC2 или контейнеров с использованием Amazon SQS.
y Сообщение в сервисе очереди остается даже при возникновении сбоя в экземпляре Amazon EC2. Этот факт очень важен для поддержания целостности
данных и отказоустойчивости системы, так как он гарантирует, что обработка будет возобновлена, когда сервер снова станет работоспособен. Такая
архитектура создает устойчивую систему, которая способна пережить сбой
сервера и восстановиться без потери критических данных.
Вы можете столкнуться с колебаниями нагрузки на приложение, которые способны привести к непредвиденным нагрузкам сообщений. Автоматизация рабочей
нагрузки с использованием паттерна «Цепочка очередей» поможет справиться
с любыми колебаниями. Давайте узнаем больше о применении в таких ситуациях
паттерна Job Observer (Наблюдатель заданий).
228
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Паттерн Job Observer (Наблюдатель заданий)
Паттерн «Цепочка очередей» помогает спроектировать слабосвязанную архитектуру, но что делать с выбросами рабочей нагрузки? При колебании количества
запросов необходимо регулировать вычислительные мощности в зависимости
от потребностей пользователей; в этом может помочь паттерн Job Oserver «Наблюдатель заданий».
В паттерне «Наблюдатель заданий» можно создать группу автомасштабирования
на основании количества сообщений, ожидающих обработки в очереди. Паттерн
помогает поддерживать производительность за счет увеличения или уменьшения количества экземпляров серверов, используемых при обработке задания.
На рис. 5.9 изображена архитектура этого паттерна.
AWS Auto Scaling
добавление нового сервера
Порог
сообщений
Размещение
сообщения
EC2
Amazon CloudWatch
отслеживание порога
очередисообщения
Получение сообщения
Очередь сообщений
EC2
Рис. 5.9. Архитектура паттерна Job Observer («Наблюдатель заданий»)
На представленной диаграмме первый парк серверов Amazon EC2 (слева) выполняет пакетные задания и помещает сообщения в очередь (например, метаданные
изображений). Второй парк серверов EC2 (справа) потребляет и обрабатывает
эти сообщения — например, при кодировании изображений. Когда количество
сообщений достигает определенного порога, Amazon CloudWatch инициирует
автомасштабирование, чтобы включить дополнительный сервер в парк потребителей для ускорения обработки заданий. Автомасштабирование также удаляет
лишние серверы, когда величина очереди падает ниже порога.
Вычисления в паттерне «Наблюдатель заданий» масштабируются по размеру
задания, обеспечивая эффективность и экономию затрат. Архитектура паттерна
Архитектура Pipes-and-Filters (Каналы и фильтры)
229
обеспечивает быстрое завершение задания. Процесс является устойчивым, это
означает, что обработка задания не прерывается в случае сбоя сервера.
Хотя архитектура на базе очереди обеспечивает слабую связанность, она работает
в основном по асинхронному pull-методу, когда потребитель может извлекать
сообщения из очереди при их появлении.
В облачно-ориентированных архитектурах бывает полезно добавить небольшие
независимые шаги между архитектурными компонентами, когда одно событие
должно инициировать другие события. Чтобы реализовать такую схему, рассмотрим архитектуру Pipes-and-Filters (Каналы и фильтры).
Архитектура Pipes-and-Filters
(Каналы и фильтры)
y
y
Архитектура «Каналы и фильтры» — паттерн проектирования, который делит
сложные задачи на серию стадий, то есть меньших независимых этапов обработки. На каждой стадии выполняется определенная операция с входными
данными и преобразованные данные передаются на следующую стадию через
так называемый канал (pipe). Стадии называются фильтрами (filters), а связи
между ними — каналами. Давайте взглянем поближе на основные компоненты
этой архитектуры.
y Фильтры — блоки, выполняющие определенные операции с данными.
Фильтры читают входные данные, обрабатывают их и производят выходные
данные. Каждый фильтр работает независимо от других и может разрабатываться и тестироваться отдельно.
y Каналы — связи, по которым передаются данные между фильтрами. Это могут
быть простые потоки данных или более сложные механизмы — например,
очереди сообщений с буферизацией, синхронизацией и преобразованиями
формата данных.
Основное преимущество этого архитектурного паттерна — надежная структура,
которая способствует разделению ответственности и модульности, упрощая понимание, изменение и обслуживание сложных систем. Его ценят за возможности
повторного использования, компоновки, последовательную обработку и масштабируемость. Отдельные фильтры, которые выполняют задачи обработки, могут
повторно использоваться в разных приложениях, обеспечивая согласованность
поведения и сокращая время разработки. Компоновка фильтров позволяет
создавать сложные цепочки обработки, которые можно легко изменять, меняя
фильтры местами по мере необходимости.
Данные передаются по каналам четко и последовательно, что дает возможность
каждому фильтру преобразовывать данные шаг за шагом, упрощая понимание
и обслуживание системы. Кроме того, паттерн поддерживает масштабируемость, так как фильтры могут работать параллельно и распределяться между
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.
Применение
фильтров
Amazon SNS
Amazon SQS
AWS Lambda
Шлюз Amazon
API Gateway
Приложение для
отправки фотографий
пользователя
Amazon S3
Уведомление
по электронной почте
AWS Lambda
Генерирование миниатюры
Рис. 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.
Шлюз Amazon
API Gateway
Определение эффективности
рекламы Anomalies — Аномалии
Anomalies
Amazon SNS
AWS Lambda
Amazon
Kinesis Data
Stream
Amazon
Kinesis Data
Analytics
Данные посещений
от разных
пользователей
Amazon S3
Amazon
Kinesis Data
Firehose
HTTP-уведомление Уведомление
других сервисов по электронной
почте
Рис. 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 отправляет уведомление по электронной почте рекламному отделу. В этой архитектуре поток событий непрерывен, а AWS Lambda читает из
него данные, относящиеся к конкретному событию.
y
y
y
y
y
В модели EDA производители и потребители работают независимо, а события
выступают в роли коммуникационной среды. Такое деление означает, что производители могут отправлять события, не зная, какие потребители будут их
обрабатывать, а потребители могут прослушивать интересующие их события, не
зная, кто их произвел. Такой подход приводит к созданию гибкой и расширяемой
системы, в которую могут добавляться новые потребители для обработки событий без изменения существующих производителей; это расширяет возможности
масштабирования и адаптируемости. Тем не менее наряду с преимуществами
архитектура, управляемая событиями, подразумевает и проблемы, которые
придется решать.
y Предотвращение повторяющейся обработки: в распределенных системах
одно событие может доставляться многократно из-за повторных попыток
передачи по сети или выхода сервисов из строя. Реализация идемпотентности
в потребителях событий гарантирует, что многократная обработка события
не приведет к некорректному поведению или несогласованности данных.
y Обработка сообщений об ошибках: надежно спроектированная архитектура EDA должна иметь эффективный механизм обработки ошибок. Он
может включать очередь недоставленных сообщений, в которых события
не могут обрабатываться и хранятся для последующего анализа или повторных попыток, а также логику обработки ошибок в потребителях, которая будет управлять исключениями без нарушения работоспособности
всей системы.
y Упорядочение событий: обработка событий в правильном порядке может
быть очень важна. При этом могут использоваться паттерны упорядочения
или механизм порождения событий для поддержания порядка для каждой
сущности.
y Отслеживание и мониторинг событий: по мере масштабирования системы
становится важно отслеживать поток событий и проводить мониторинг
работоспособности системы. Правильная реализация механизмов ведения
журнала, трассировки и оповещения позволяет получить информацию о работе системы и проводить быструю диагностику проблем.
y Управление схемой событий: по мере эволюции системы схемы событий
могут изменяться. Управление этими изменениями без нарушения работоспособности системы требует создания реестра схем и стратегии управления
версиями, чтобы потребители правильно понимали разные версии событий.
234
Глава 5. Паттерны проектирования облачно-ориентированных архитектур
Хотя архитектура, управляемая событиями, облегчает масштабируемость и расширяемость, она требует тщательного проектирования с учетом особенностей
эксплуатации, чтобы обеспечить устойчивость, согласованность и удобство
обслуживания системы.
В модульной архитектуре для достижения полноценной масштабируемости
очень важно обеспечить модульность на всех архитектурных уровнях. Перейдем
к рассмотрению паттерна проектирования BFF, который служит для соблюдения
этого принципа.
Паттерн BFF (Backend for Frontend)
Паттерн BFF (Backend for Frontend, то есть бэкенд для фронтенда) — облачно-ориентированный архитектурный паттерн, который адаптирует сервисы
бэкенда для каждой конкретной разновидности фронтенд-приложений. Паттерн BFF появился в ответ на растущую сложность современных мобильных
и веб-приложений. Он подразумевает создание разных сервисов бэкенда, адаптированных для каждого фронтенда или взаимодействия с пользователем. Тем
самым BFF упрощает фронтенд-разработку и оптимизирует ответы бэкенда
к уникальным требованиям каждого фронтенда.
y
y
y
y
Кратко охарактеризуем основные особенности паттерна BFF.
y Адаптированные API: каждый фронтенд (например, веб-приложение, мобильное приложение, смарт-ТВ) имеет собственный бэкенд-сервис (BFF),
адаптированный для своих специфических потребностей. BFF предоставляют
API, которые поставляют только данные, необходимые фронтенду, в подходящем формате. Такой подход сокращает необходимость преобразования
данных на фронтенде и приводит к оптимизации ответов API.
y Упрощение фронтенд-разработки: фронтенд-разработчики могут активно использовать BFF для повышения эффективности совместной работы
и ускорения циклов разработки. Реализации BFF можно писать на том же
языке, что и фронтенд; это поможет фронтенд-разработчикам понять и изменить бэкенд.
y Делегирование сложности: BFF могут решать задачи, которыми в противном
случае занимался бы фронтенд: аутентификацию, агрегирование данных и обработку ошибок. Делегирование сложности сокращает рабочую нагрузку на
фронтенд и повышает качество пользовательских взаимодействий.
y Независимое развитие: каждый сервис BFF может развиваться независимо,
что упростит развертывание обновлений и функциональности для конкретных фронтендов без последствий для других. BFF работают как адаптеры
между фронтендами и базовыми бэкенд-сервисами, сводя к минимуму
влияние изменений на каждом уровне.
Рассмотрим приложение интернет-магазина с фронтендами для веб-приложений,
мобильных приложений и смарт-ТВ.
Облачно-ориентированные архитектурные антипаттерны
235
y
y BFF для веб: предоставляет подробные описания товаров, отзывы пользова-
y
y
телей и рекомендации для веб-фронтенда. Агрегирует данные от нескольких
бэкенд-сервисов (информацию о товарах, пользовательские профили, рекомендательные системы). Преобразует данные в формат, пригодный для
отображения в веб-браузерах.
y Мобильный BFF: предоставляет упрощенные описания товаров, отзывы
пользователей и рекомендации, оптимизированные для мобильных устройств.
Решает такие задачи, как масштабирование изображений для меньших экранов. Агрегирует данные и адаптирует их для специфических потребностей
мобильного фронтенда.
y 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
ФАКТОРЫ
ПРОИЗВОДИТЕЛЬНОСТИ
Эксперименты показывают, что каждая секунда задержки при загрузке приложения значительно снижает доход организаций. Следовательно, производительность приложения является одним из самых важных его параметров, влияющим
на уровень принятия продукта пользователями.
y
y
y
y
y
В предыдущей главе обсуждались паттерны проектирования, которые могут
использоваться для решения сложных бизнес-задач. В этой главе рассматриваются некоторые лучшие практики оптимизации приложений, которые следует
применять на каждом уровне и со всеми архитектурными компонентами. Вы
узнаете, как выбрать правильную технологию для разных уровней архитектуры,
чтобы непрерывно улучшать производительность приложения. Эта глава будет
посвящена следующим темам.
y Принципы проектирования высокопроизводительных архитектур.
y Выбор технологии для оптимизации производительности.
y Факторы производительности для мобильных приложений.
y Тестирование производительности.
y Мониторинг производительности.
К концу главы вы будете понимать важнейшие факторы производительности — такие, как задержка, пропускная способность и параллелизм. Вы сможете
совершать более обоснованный выбор технологии, чтобы улучшить производительность на разных уровнях архитектуры: вычисления, хранение информации,
базы данных и сетевые взаимодействия.
Принципы проектирования
высокопроизводительных архитектур
Производительность архитектуры подразумевает использование инфраструктуры приложения и доступных ресурсов для удовлетворения растущих потребностей и технологической эволюции. Производительность заставляет архитекторов
Принципы проектирования высокопроизводительных архитектур
241
создавать системы, которые не только отвечают текущим потребностям, но
и обладают достаточной гибкостью для масштабирования и развития, чтобы
поддерживать производительность стабильно высокой и соответствующей
ожиданиям пользователей и изменениям технологий.
Рассмотрим некоторые важные принципы проектирования для оптимизации
производительности рабочей нагрузки.
Сокращение задержки
Задержка (latency) может значительно повлиять на популярность продукта
у пользователей, потому что они предпочитают самые быстрые приложения.
Где бы ни находились пользователи, вы должны предоставить им эффективный
и надежный сервис. Задержкой называется время, необходимое для передачи
пакета данных из одной определенной точки в другую. Если выражаться проще,
это время между инициированием действия и появлением ответа на устройстве
или в системе. На задержку могут влиять разные факторы, включая физическое
расстояние между клиентом и сервером, скорость среды передачи (например,
оптоволоконный кабель или беспроводной сигнал) и занятость сети.
Представьте, что вы просматриваете веб-сайт. Когда вы кликаете на ссылке
или нажимаете кнопку, запрос передается от устройства серверу сайта. Сервер
может находиться в том же городе, что и вы, а может — на другом конце света.
Время, необходимое для того, чтобы запрос попал на сервер, тот обработал этот
запрос, а затем вернул ответ, и формирует то, что мы называем задержкой. Достичь нулевой задержки невозможно, но необходимо стремиться к тому, чтобы
время реакции не превышало предел ожидания пользователей.
Представьте сценарий (рис. 6.1), где передача сообщения от устройства к серверу занимает 600 миллисекунд (мс); это может быть связано с физическим
расстоянием, которое должны преодолеть данные, или с тем, что пакеты
данных маршрутизируются через несколько промежуточных устройств —
маршрутизаторов, коммутаторов и т. д. Если серверу требуется еще 900 мс
для обработки запроса и отправки ответа, то общая фактическая задержка
составит 1,5 секунды (1500 мс). Этого достаточно, чтобы заметить задержку
при загрузке веб-страницы.
600 мс
Клиент
900 мс
Сервер
Рис. 6.1. Задержка между запросом и ответом в модели «клиент — сервер»
242
Глава 6. Факторы производительности
В наше время любому приложению необходим выход в интернет, чтобы иметь
доступ к широкой аудитории глобальных пользователей. Эти пользователи
ожидают стабильной производительности независимо от своего географического
положения. Иногда обеспечить соответствие их ожиданиям непросто, поскольку
перемещение данных по сети из одной части света в другую требует времени.
Сетевую задержку могут вызывать различные факторы, например сетевая среда передачи данных, переходы маршрутизаторов и распространение сигнала.
В корпоративных средах для соединения корпоративной сети с облаком обычно
используется оптоволоконная линия, чтобы избежать несогласованности данных. Организации также могут пользоваться сетями распространения контента
(CDN) для хранения тяжелых графических и видеоданных рядом с пользователем для снижения сетевой задержки и улучшения производительности.
С периферийными ячейками проще развертывать рабочие нагрузки вблизи
пользовательской базы.
Кроме сети, задержка может возникать в компонентах архитектуры. На вычислительном сервере задержка может проявляться на уровне инфраструктуры, так
как передача данных между процессором и оперативной памятью выполняется
относительно медленно. Диск может создавать задержку из-за медленных операций чтения и записи. Задержка на жестком диске (HDD) зависит от времени, необходимого для выбора сектора памяти диска и для того, чтобы головка
диска совпала с выбранным сектором для чтения и записи. Дисковая память
представляет собой физическую область хранения данных на диске. На HDD
данные распределяются по секторам в ходе операций записи. Так как диск постоянно вращается, данные могут распределяться по нему в непредсказуемом
порядке. В ходе операций чтения считывающая головка должна дождаться, пока
в результате вращения она окажется у нужного сектора.
На уровне базы данных задержка может вызываться медленными операциями
чтения и записи из-за «узких мест» оборудования или медленной обработки
запросов. Снижение нагрузки на базу данных за счет распределения данных
при сегментации и шардировании может уменьшить задержку.
Так как задержка и пропускная способность напрямую связаны, низкая задержка
означает повышение пропускной способности. Давайте поближе познакомимся
с этим понятием.
Повышение пропускной способности
Пропускной способностью (throughput) сети называется объем данных, которые могут быть успешно переданы по сети в определенный период времени. Эта
метрика необходима для понимания того, насколько эффективно работает сеть
при заданных условиях и нагрузке. На пропускную способность могут влиять
разные факторы, включая емкость сети, качество соединения и протоколы,
используемые для передачи данных. Емкость сети определяет максимальный
объем данных, которые могут быть переданы по ней.
Принципы проектирования высокопроизводительных архитектур
243
Пропускная способность и задержка напрямую связаны. Низкая задержка означает высокую пропускную способность, потому что больший объем данных
передается за меньшее время. Чтобы лучше понять, почему это так, воспользуемся аналогией с транспортной инфраструктурой страны.
Будем считать шоссе с несколькими полосами движения аналогом сетевых
каналов, а машины — аналогами пакетов данных. Представим, что 16-полосное
шоссе связывает два города. Не все машины достигают точки назначения за
нужное время: они могут задерживаться из-за пробок, закрытия полос или ДТП.
В этом примере задержка определяет, как быстро машина может добраться от
одного города до другого, а пропускная способность — сколько машин сможет
добраться до цели. Использовать полную емкость может быть трудно из-за
ошибок и пробок.
Пропускная способность сети измеряется объемом данных, передаваемым по
сети в битах в секунду (бит/с). Емкость сети определяется максимальным объемом данных, которые могут быть обработаны в сетевом пайплайне. На рис. 6.2
изображена схема передачи данных между клиентом и сервером.
Пакет сообщения
Сервер
Клиент
Рис. 6.2. Передача данных в сети
Кроме сети, концепция пропускной способности применима на уровне дисковых
накопителей. Пропускная способность диска — критическая метрика, описывающая, насколько быстро данные читаются с устройства хранения или записываются на него. Она измеряется в мегабайтах в секунду (Мбайт/с) и зависит от
двух основных факторов: количества операций ввода/вывода в секунду (IOPS)
и размера каждой операции ввода/вывода (средний размер ввода/вывода).
Пропускная . Средний размер операции ввода/вывода (байты) × IOPS
.
способность . =
10242
(Мбайт/с)
y
Компоненты этой формулы:
y средний размер операции ввода/вывода — средний размер каждой операции
чтения или записи в байтах. Изменяется в зависимости от рабочей нагрузки;
например, операции с базами данных могут иметь меньший размер операций
ввода/вывода по сравнению с потоковой передачей больших видеофайлов;
244
Глава 6. Факторы производительности
y
y IOPS (количество операций ввода/вывода в секунду) определяет, сколько
y
операций чтения или записи может обработать накопитель за секунду. Высокое значение IOPS характерно для быстрых систем хранения, способных
параллельно обрабатывать множество операций;
y пропускная способность (Мбайт/с) оценивает фактическую скорость
передачи данных накопителя. Она объединяет IOPS со средним размером
операции ввода/вывода для представления объема данных, который может
быть перемещен в систему хранения или из нее за секунду.
Чтобы преобразовать результат в Мбайт/с, мы делим произведение среднего
размера операции ввода/вывода и IOPS на 1024*1024 (1024 байт в килобайте,
1024 килобайта в мегабайте).
При IOPS дискового устройства = 20 000 и размере операции ввода/вывода =
4 Кбайт (4 * 1024 байта = 4096 байт) пропускная способность вычисляется, как
описано ниже.
1. Сначала размер ввода/вывода преобразуется из байтов в мегабайты:
размер операции ввода/вывода в Мбайт = 4.096 байт = 0.00390625 Мбайт.
1024 × 1024
2. Затем результат умножается на IOPS для получения пропускной способности в Мбайт/с:
пропускная способность = размер операции ввода/вывода в Мбайт × IOPS;
пропускная способность = 0,00390625 Мбайт × 20 000;
пропускная способность = 78,125 Мбайт.
Таким образом, при IOPS дискового устройства = 20 000 и размере операции
ввода/вывода = 4 Кбайт пропускная способность составит приблизительно
78,125 Мбайт/c.
В результате этих вычислений мы получаем общий объем данных, которые могут
быть прочитаны или записаны на диск за секунду при этих условиях.
На уровне операционной системы пропускная способность определяется объе
мом данных, передаваемых между процессором и оперативной памятью за секунду. На уровне базы данных пропускная способность определяется количеством
транзакций, которые могут быть обработаны базой данных за секунду. На уровне
приложения код должен обрабатывать транзакции, которые могут выполняется
каждую секунду, управляя памятью приложения с помощью системы сборки
мусора и эффективного использования кэша в памяти.
Когда речь заходит о задержке, пропускной способности и емкости, также
необходимо учитывать фактор конкурентности, который действует на разные компоненты архитектуры и помогает повысить производительность
приложения. В следующем разделе тема конкурентности рассматривается
более подробно.
Принципы проектирования высокопроизводительных архитектур
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.
Впрочем, организации обычно выбирают стандартный вариант: серверы с виртуальными машинами. Контейнеры также приобретают популярность, так
как потребность в автоматизации и использовании ресурсов возросла. Сейчас
контейнерам отдают предпочтение, особенно в области развертывания микросервисных приложений.
Оптимальный выбор вычислительного ресурса — независимо от того, выбрали
ли вы экземпляры серверов, контейнеры или бессерверные схемы, — зависит
от сценария использования приложения. Рассмотрим различные варианты вычислительных ресурсов.
y
y
В таблице 6.1 приведена сводка различий между процессорами (CPU),
графическими процессорами (GPU), программируемыми пользователем
вентильными матрицами (FPGA) и специализированными интегральными
схемами (ASIC) с акцентом на их основные области применения, простоту
программирования, архитектуру ядер, стоимость и пригодность для параллельных вычислений, а также другие характеристики. Для начала определимся
с терминами.
y Центральный процессор (CPU, Central Processing Unit) — центральный
процессор компьютера, выполняющий бˆольшую часть операций обработки
данных; часто сравнивается с «мозгом» компьютера.
y Графический процессор (GPU, Graphic Processing Unit) — специализированная микросхема, предназначенная для быстрого выполнения операций
Выбор технологии для оптимизации производительности
249
y
y
и модификации памяти, чтобы ускорить создание изображений в буфере
кадра, предназначенном для вывода на экран.
y Программируемая пользователем вентильная матрица (FPGA, Field
Programmable Gate Array) — интегральная схема, которая должна настраиваться клиентом или проектировщиком после производства — отсюда
«программируемая».
y Специализированная интегральная схема (ASIC, Application-Specific
Integrated Circuit) — микросхема, специализированная для целевого (не
универсального) применения.
Можно использовать один или несколько вариантов этих процессоров в зависимости от рабочей нагрузки.
Таблица 6.1. Сравнение разных типов вычислительных ресурсов
Особенность
CPU
GPU
FPGA
ASIC
Основное
применение
Приложения общего назначения
Работа с графикой, обработка
больших данных
Программируемое устройство
для специа
лизированных
задач
Специализированные целевые
интегральные
схемы
Простота
программирования
Просто
Требует знания
специализированных библиотек (например,
CUDA)
Сложное, требует навыков
аппаратного
программирования
– (устройство
проектируется
для единственной
цели)
Многозадачность
Да
Ограничивается Да — при измеподдержкой
нении конфигупараллелизма
рации
при проектировании
Нет — узкоспе
циализированное
устройство
Универсальность
Высокая
Умеренная
Умеренная,
возможно изменение конфигурации для конкретных задач
Низкая, привязка
к применению
Метрика производительности
ГГц (миллиарды
тактов
в секунду)
TFLOP
(триллионы
операций с плавающей точкой
в секунду)
Может измеряться в FLOP
(операциях
с плавающей
точкой в секунду)
Оптимизируется
для снижения
энергопотребления и увеличения
производительности
Структура
ядра
Несколько
больших
ядер
Тысячи небольших ядер
Логические эле- Нет — узкоспе
менты, которые циализированное
можно пере
устройство
настраивать
250
Глава 6. Факторы производительности
Продолжение
Особенность
CPU
GPU
FPGA
ASIC
Параллельная обработка
Ограничена
Высокая,
с массово-параллельной обработкой (MPP,
Massively Parallel Processing)
Поддерживает
MPP, настраивается как CPU
Оптимизируется
для конкретных
применений
Затраты
Низкие
Выше, чем
у CPU
Выше, чем
у CPU и GPU,
требует настройки
Самые высокие
из-за нестандартной архитектуры
и долгого цикла
разработки
Энергопотребление
Умеренное
Высокое
Низкое
Оптимизировано
для применения
Гибкость
Универсальность
в широком
спектре
применений
Специализирована для применений с интенсивными
вычислениями
Может перенастраиваться, но
требует разработки
Фиксированное
применение,
требует перепроектирования для
изменений
Цикл разработки
Короткий
От короткого до
умеренного
Длинный из-за
необходимости
пользовательской настройки
Самый длинный,
требует перепроектирования на
уровне оборудования
В табл. 6.1 сравниваются разные типы вычислительных ресурсов. ASIC — самый
эффективный вариант, но требует длительного цикла разработки для реализации.
ASIC обеспечивает оптимальную производительность, но имеет наименьшую
гибкость для перепрофилирования, тогда как CPU чрезвычайно гибкие и подходят для многих сценариев использования.
В наши дни CPU получили широкое распространение и применяются повсеместно для устройств общего назначения в целях снижения затрат. GPU
весьма популярны в приложениях с интенсивными вычислениями, а 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 и установить связи между ними.
На каждом из этих уровней могут существовать свои измененные версии
библиотек, а Docker позволяет им работать на одном вычислительном ресурсе
без конфликтов.
252
Глава 6. Факторы производительности
Образы контейнеров Docker могут портироваться между системами по локальной
сети или по интернету с использованием Docker Hub. Для управления контейнерами и их распространения можно воспользоваться репозиторием контейнеров
Docker Hub. Допустим, вы внесли в образ Docker изменения, которые вызвали
проблемы в среде. В этом случае можно легко вернуться к работоспособной
версии образа, что заметно упрощает устранение неполадок.
При использовании Docker команда разработки строит приложение и упаковывает его с необходимыми зависимостями в образ. Этот образ выполняется
в контейнере на хосте Docker. По аналогии с управлением кодом в репозиториях
(например, GitHub) образы Docker также должны храниться в реестре. Docker
Hub — общедоступный реестр, а другие провайдеры публичных облачных
платформ предоставляют собственные реестры — например, AWS ECR (Elastic
Container Registry) и Azure Container Registry. Кроме того, можно создать свой
локальный приватный реестр для образов Docker.
Провайдеры публичных облачных платформ (таких, как AWS) предоставляют
платформы управления контейнерами — например, Amazon ECS. Эти средства
позволяют управлять контейнерами Docker поверх облачной виртуальной машины, Amazon EC2. AWS также предлагает бессерверный вариант развертывания
контейнеров на базе Amazon Fargate, позволяющий развертывать контейнеры
без виртуальной машины.
Сложные корпоративные приложения строятся на базе микросервисов, которые
могут охватывать несколько контейнеров. Управлять разными контейнерами
Docker как частью приложения может быть непросто. Платформа Kubernetes
помогает решать проблемы мультиконтейнерных сред.
Познакомимся с Kubernetes поближе.
Kubernetes
Kubernetes превосходно проявляет себя в управлении и координации нескольких
контейнеров в рабочей среде, действуя как всесторонняя система оркестрации
контейнеров. Kubernetes поддерживает размещение контейнеров Docker на физических серверах или узлах виртуальных машин, которые обычно называются
рабочими узлами. Kubernetes эффективно координирует операции в кластерах
таких узлов, автоматизируя развертывание, масштабирование и управление
контейнеризованными приложениями, что гарантирует плавную и надежную
работу приложения в инфраструктуре.
Kubernetes обеспечивает самовосстановление приложений, так как контейнеры, не отвечающие из-за ошибки приложения, автоматически заменяются.
Kubernetes также предоставляет возможности горизонтального масштабирования и сине-зеленого развертывания для предотвращения простоев. Kubernetes
распределяет нагрузку пользовательского трафика между контейнерами
и управляет пространством хранения, совместно используемым разными
контейнерами.
Выбор технологии для оптимизации производительности
253
На рис. 6.4 показано, как Kubernetes и Docker совместно работают над оркестрацией приложения. Kubernetes обеспечивает сетевые коммуникации между
рабочими узлами и контейнерами Docker.
Ядро Kubernetes
Docker
Network
Etcd
Kubelet
Master
Узел 1
Узел 2
Кластер Kubernetes
Рис. 6.4. Docker и Kubernetes
Docker работает как отдельная часть приложения, а 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), а GCP — сервис GKE (Google Kubernetes Engine),
предлагающие простые средства для развертывания, масштабирования и автоматического управления Kubernetes.
В целом контейнеры добавляют уровень виртуализации во всю инфраструктуру
приложения. Они полезны для эффективного использования ресурсов, но если
приложение требует сверхнизкой задержки, выбирайте физическую машину
для его развертывания.
Бессерверные решения
Бессерверные вычисления стали возможны благодаря популярности решений
от провайдеров публичных облачных платформ — таких, как Amazon, Google
и Microsoft. Бессерверные вычисления позволяют разработчикам сосредоточиться на коде и разработке приложения, не беспокоясь о нижележащей инфраструктуре масштабирования, выделения ресурсов и настройки. Бессерверные
решения абстрагируют управление серверами и инфраструктурой, отделяют эти
процессы от разработчика и позволяют ему сосредоточиться на своей области
компетенции и бизнес-задачах, которые он решает. Бессерверные вычисления
приводят нас к относительно новой концепции «функция как сервис» (FaaS,
Function as a Service).
Предложения FaaS доступны от AWS Lambda, Microsoft Azure Functions и Google
Cloud Functions. Например, можно написать код в облачном редакторе, а AWS
Lambda возьмет на себя управление нижележащей вычислительной инфраструктурой для выполнения и масштабирования написанных функций. Можно спроектировать архитектуру, управляемую событиями, или RESTful-микросервисы,
добавив конечную точку API при помощи Amazon API Gateway и функций AWS
Lambda. Amazon API Gateway — обслуживаемая облачная система, которая
добавляет RESTful-API и WebSocket API в качестве фронтендов для функций
Lambda и делает возможными коммуникации между приложениями в реальном
времени. Можно продолжить разбиение микросервисов на меньшие задачи,
которые могут масштабироваться автоматически и независимо.
Помимо возможности сосредоточиться на коде, с моделью FaaS вам никогда
не придется платить за простаивающие ресурсы. Вы можете независимо масштабировать только необходимые функции, а не весь сервис, со встроенными
средствами доступности и отказоустойчивости. Однако при необходимости
Выбор технологии для оптимизации производительности
255
оркестрировать тысячи компонентов предсказать затраты на автомасштабирование может быть непросто. Такое решение идеально подходит для планирования
заданий, обработки веб-запросов и ведения очередей сообщений.
В этом разделе вы узнали о том, какие вычислительные ресурсы могут использоваться для оптимизации производительности. Мы рассмотрели экземпляры серверов, контейнеры и бессерверные решения. Выбирайте сервисы в соответствии
с требованиями своего приложения. Не существует правил, предопределяющих
выбор конкретного способа вычислений; все зависит от технологического стека
организации, темпа инноваций и природы приложения.
Как бы то ни было, для монолитных приложений обычно можно без особого
риска выбрать виртуальную или физическую машину, а для сложных микросервисов — контейнеры. Для планирования простых задач или приложений,
управляемых событиями, бессерверные функции — очевидный вариант. Многие
организации строят сложные приложения полностью на бессерверных вычислениях, что помогает им сократить затраты и добиться высокой доступности
без необходимости управлять инфраструктурой.
Рассмотрим другой важный вопрос инфраструктуры и то, как его решение может
помочь в оптимизации производительности.
Выбор типа хранилища
Хранение данных играет ключевую роль в производительности любого приложения, и концепция локальности данных (data affinity) чрезвычайно важна при
обсуждении организации хранения в приложении. Под локальностью данных
понимается стратегическое размещение данных рядом с приложением, которое
эти данные потребляет, с целью сокращения задержки, повышения производительности и обеспечения эффективного чтения данных.
В мультиоблачных или гибридных облачных средах представление о том, что все
данные должны храниться в непосредственной близости от сервера приложения,
не всегда истинно. Современные распределенные системы проектируются так,
чтобы данные могли храниться в разных местах — как локально, так и у других
облачных провайдеров, при этом сохраняя приемлемые уровни задержки и производительности. Такая гибкость критична для организаций, использующих
разные облачные сервисы, или для организаций, у которых, согласно требованиям к хранению, некоторые данные должны оставаться в определенных географических или законодательных границах.
y
Тем не менее при принятии решений о том, где должны храниться данные —
рядом с сервисом приложения или в другом месте, — необходимо тщательно
взвесить ряд факторов.
y Требования к задержке: допустимая задержка между запросом и ответом
может значительно повлиять на выбор места хранения. Приложения, которым необходима доступность данных в реальном времени, могут требовать
256
Глава 6. Факторы производительности
y
y
y
y
y
способов хранения с минимальной задержкой, что часто подразумевает
близкое размещение (физическое или сетевое).
y Суверенитет данных и комплаенс: юридические и нормативные требования могут предписывать, где должны храниться и обрабатываться данные.
Архитектура должна соответствовать этим требованиям.
y Затраты: хранение и работа с данными, расположенными в разных местах
или облачных платформах, могут приводить к дополнительным затратам.
Очень важно сочетать требования к производительности с ограничениями
бюджета, особенно с учетом платы за исходящие данные в облачных средах.
y Емкость и пропускная способность: емкость и пропускная способность
сети между сервером приложения и местом хранения данных могут влиять
на производительность. Высокая емкость и пропускная способность могут
решить некоторые проблемы с задержкой, делая доступными более гибкие
варианты хранения данных.
y Шаблоны обращения к данным: если вы имеете представление о том, как
ваше приложение обращается к данным (например, к каким данным оно
обращается часто, а к каким редко), это поможет вам выбрать подходящее
хранилище. Если данные, к которым приложение обращается часто, хранятся
рядом с ним, это может ускорить доступ.
y Аварийное восстановление и доступность: стратегии устойчивости данных
могут требовать, чтобы данные реплицировались в разных местах для обес
печения доступности в случае сбоев.
В мультиоблачных стратегиях кэширование, репликация данных или периферийные вычисления могут помочь с соблюдением стандартов производительности за счет хранения синхронизированной копии критических данных рядом
с приложением независимо от места хранения основных данных. Такие приемы
позволяют приложениям обращаться к данным с минимальной задержкой, даже
если первоисточник данных находится на значительном удалении.
Выбор способа хранения зависит от тщательного анализа перечисленных факторов. Старайтесь выдержать баланс между эксплуатационными требованиями,
производительностью, затратами и обеспечением комплаенса. Ваша конечная
цель — создать решение, удовлетворяющее требованиям к производительности
и при этом соблюдающее организационные, юридические и бюджетные ограничения.
Сначала необходимо решить, должны ли данные содержаться в блоковом,
файловом или объектном хранилище. В этих форматах данные хранятся и представляются по-разному. Рассмотрим их более подробно.
Блоковые хранилища и сети хранения данных
Блоковое хранилище делит данные на блоки и хранит их как фрагменты данных.
Каждый блок обладает уникальным идентификатором, что позволяет системе
размещать данные там, где они будут наиболее легкодоступны, так как в блоках
Выбор технологии для оптимизации производительности
257
не хранятся никакие метаданные о файлах. Серверная операционная система
управляет этими блоками на жестком диске и использует их. Каждый раз, когда
система запрашивает данные, система хранения собирает нужные блоки и возвращает результат пользователю.
Блоковое хранилище, развернутое в сети хранения данных (SAN, storage area
network), эффективно в тех случаях, когда требуется хранить большой объем данных, к которым необходимо часто обращаться — например, при развертывании
базы данных, серверов электронной почты, приложения и виртуальных машин.
В SAN используется комплексная система хранения, способная обеспечить работу
сложных, критически важных приложений. Это высокопроизводительная система
хранения, передающая блоковые данные между сервером и хранилищем; с другой
стороны, решения 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. Факторы производительности
Реляционная модель может обрабатывать в приложениях сложные бизнес-операции: банковские, торговые и т. д. Она позволяет агрегировать данные и создавать
сложные запросы с соединением нескольких таблиц.
y
y
y
y
В процессе оптимизации реляционной базы данных необходимо учитывать
следующее.
y Сервер базы данных и его отдельные параметры: вычислительная мощность,
память, хранилище и сеть.
y Настройки уровня операционной системы: тома для хранения, управление
томами и размер блока.
y Конфигурация и секционирование ядра базы данных.
y Средства, относящиеся к базе данных: схемы, индексы, представления.
Масштабирование реляционных баз данных затруднено, так как они масштабируются вертикально и достигают верхнего предела мощности системы. Используйте реплики для чтения, чтобы распределить нагрузку. Это позволит сместить
запросы чтения с основной базы данных на одну или несколько реплик, улучшая
общую пропускную способность системы для чтения. Для масштабирования
записи реализуйте шардирование. Разбивая большой набор базы данных на
меньшие, более удобные части (сегменты, или шарды), каждая из которых имеет
свое подмножество данных, можно распределить нагрузку записи по нескольким
серверам или экземплярам, тем самым повышая эффективность записи.
В главе 4 вы узнали, как масштабировать реляционную базу данных (раздел
«Работа с базой данных в архитектуре приложения»).
Базы данных OLTP подходят для больших и сложных транзакционных приложений; однако из-за необходимости агрегировать большие объемы данных
и обрабатывать запросы к ним возникает потребность в более эффективном
масштабировании. Кроме того, с развитием интернета отовсюду поступает
много неструктурированных данных, а реляционные БД в исходной форме не
могут эффективно работать с ними. На помощь приходят нереляционные базы
данных (NoSQL). Рассмотрим работу с ними более подробно.
Нереляционные базы данных
Приложения (социальные сети), IoT (интернет вещей), данные истории просмотров и журналы генерируют огромное количество неструктурированных или
полуструктурированных данных с чрезвычайно динамичными схемами. Эти
типы данных могут использовать разные схемы для каждого набора записей.
Хранение таких данных в реляционной БД может оказаться очень утомительной задачей. Все необходимо преобразовать к фиксированной схеме, что может
привести либо к появлению множества значений null, либо к потере данных.
Нереляционные базы данных, обычно обозначаемые сокращением NoSQL («Not
Only SQL», то есть «не только SQL»), предоставляют гибкий подход к хранению
и управлению данными. В отличие от традиционных реляционных БД, которые
Выбор технологии для оптимизации производительности
263
требуют создать фиксированную схему перед сохранением данных, базы данных
NoSQL позволяют хранить данные и управлять ими без предварительно определенных ограничений схемы. Записи с разным количеством столбцов могут
храниться в одной таблице.
Базы данных NoSQL способны хранить большие объемы данных и обеспечивают
низкую задержку. При необходимости они легко масштабируются добавлением
новых узлов и изначально поддерживают горизонтальное масштабирование.
Они отлично подходят для хранения данных пользовательских сессий и перехода к приложению без сохранения состояния для реализации горизонтального
масштабирования без ущерба для пользовательских взаимодействий. Можно
разработать распределенное приложение поверх базы данных NoSQL, которая
обеспечивает хорошую задержку и масштабирование, но соединение запросов
должно обрабатываться на уровне приложения, потому что базы данных NoSQL
не поддерживают сложные запросы (например, соединения таблиц и сущностей).
Существует много разных баз данных NoSQL (Cassandra, HBase, MongoDB
и т. д.), которые могут устанавливаться в кластере виртуальных машин. AWS
предоставляет управляемую базу данных NoSQL, которая называется Amazon
DynamoDB и обеспечивает высокую пропускную способность с субмиллисекундной задержкой и неограниченными возможностями масштабирования.
OLTP может использоваться с реляционными базами данных, но ограничивается
емкостью хранилища. Базы данных должны лучше реагировать на запросы больших объемов данных и проводить агрегирование в соответствии с потребностями
хранилищ. Эти потребности имеют более аналитическую, нежели транзакционную природу. OLAP заполняет пробелы в возможностях OLTP, касающихся
запросов к большим наборам данных. Рассмотрим OLAP более подробно.
OLAP
OLTP и базы данных NoSQL полезны для развертывания приложений, но их
возможности крупномасштабного анализа ограниченны. В хранилищах данных
в основном используется технология аналитической обработки данных в реальном времени, или OLAP (Online Analytical Processing). Запрос большого
объема структурированных данных для аналитических целей лучше обслуживается платформой хранилища, спроектированной для ускорения доступа
к структурированным данным. Современные хранилища данных используют
форматы колоночного, или столбцового, хранения и массово-параллельную
архитектуру (MPP, massively parallel processing) для значительного ускорения
выборки данных и анализа. В отличие от традиционных строковых баз данных,
в которых данные хранятся по строкам, в колоночном хранилище данные структурируются по столбцам (колонкам).
Колоночный формат означает, что не придется сканировать всю таблицу, если
нужно агрегировать только один столбец данных — например, если требуется
определить объем продаж за заданный месяц. Таблица заказов может содержать
264
Глава 6. Факторы производительности
сотни столбцов, но вам нужно агрегировать данные только по столбцу продаж.
С колоночным форматом достаточно сканировать один столбец, что сокращает
объем сканируемых данных по сравнению со строковым форматом и повышает
эффективность запроса.
С MPP данные хранятся в распределенном виде между дочерними узлами, и запрос отправляется ведущим узлам. На основании ключа сегментации ведущий
узел распределяет запросы между дочерними узлами. Каждый узел получает
часть запроса для выполнения параллельной обработки. Затем ведущий узел
собирает результаты подзапросов от всех дочерних узлов и возвращает агрегированный результат. Параллельная обработка помогает быстрее выполнять
запросы и обрабатывать большие объемы данных.
Для выполнения подобной обработки можно установить специализированное
ПО (например, Netezza или Microsoft SQL Server) на виртуальной машине или
же выбрать облачно-ориентированное решение (такое, как Snowlake). AWS
как публичная облачная платформа предоставляет решение Amazon Redshift
для хранения данных в петабайтовом масштабе, использующее столбцовый
формат и MPP. Вы больше узнаете об обработке данных и аналитике в главе 12
«Инженерия данных для архитектур решений».
Задача хранения и поиска в больших объемах данных возникает достаточно
часто — например, если требуется найти конкретную ошибку в журнале или построить механизм поиска документов. Для таких задач приложение должно создать
функциональность поиска данных. Эта тема рассматривается в следующем разделе.
Построение функциональности поиска данных
Часто возникает необходимость быстро провести поиск по большому объему
данных, чтобы оперативно решить проблему или получить информацию для
бизнеса. Поиск в данных приложения поможет проанализировать детализированную информацию с разных точек зрения. А чтобы провести поиск с низкой
задержкой и высокой пропускной способностью, понадобится поисковая система.
Elasticsearch — одна из самых популярных поисковых платформ, построенная
на основе библиотеки Apache Lucene — бесплатной библиотеки с открытым
исходным кодом, лежащей в основе многих популярных поисковых систем.
С помощью стека ELK (Elasticsearch, Logstash, Kibana) легко обрабатывать
крупномасштабные данные и индексировать их для автоматизации поиска. Эти
особенности помогли разработать на базе Elasticsearch многочисленные средства
визуализации и анализа. Например, Logstash использует Elasticsearch для сбора,
преобразования и анализа больших объемов журнальных данных приложений.
Kibana содержит встроенный соединитель с Elasticsearch и предоставляет
простое решение для создания дашбордов и анализа индексируемых данных.
Elasticsearch может развертываться на виртуальных машинах и масштабироваться горизонтально для повышения емкости за счет добавления новых узлов
в кластер. Публичная облачная платформа AWS предоставляет управляемый
Выбор технологии для оптимизации производительности
265
сервис Amazon OpenSearch, обеспечивающий бюджетное и простое масштабирование и управление кластером Elasticsearch в облаке.
В этом разделе вы узнали о различных технологиях баз данных и о том, в каких
ситуациях они применяются. Приложения могут использовать разные технологии баз данных в разных компонентах для достижения оптимальной производительности. Для сложных транзакций необходимо выбирать реляционную
базу данных OLTP, а для хранения и обработки неструктурированных или
полуструктурированных данных — нереляционную базу данных NoSQL. Используйте базу данных NoSQL, когда очень низкая задержка необходима в нескольких географических регионах и когда требуется обрабатывать сложные
запросы на уровне приложения (например, в играх). А для крупномасштабного
анализа структурированных данных выбирайте базу данных OLAP.
Перейдем к следующему критически важному компоненту архитектуры — сети.
Сеть является опорой всего приложения и обеспечивает связь между серверами
и внешним миром. Давайте посмотрим, как сети влияют на производительность
приложения.
Повышение производительности сети
В эпоху доступности быстрого интернета приложения должны нормально работать у каждого пользователя практически в каждом уголке мира. Любая задержка отклика системы зависит от нагрузки запросов и удаленности конечного
пользователя от сервера. Если система не будет быстро реагировать на запросы
пользователя, это может привести к цепной реакции: все ресурсы останутся
занятыми, а в системе накопится значительное количество необработанных
запросов, что приведет к снижению ее общей производительности.
Чтобы сократить задержку, смоделируйте местоположение и среду пользователя и выявите имеющиеся разрывы. Используя полученные результаты,
спроектируйте физическое местоположение сервера и механизм кэширования
для достижения минимальной задержки; впрочем, выбор сетевого решения для
приложения зависит от скорости сети, требований к пропускной способности
и задержке. Приложение с глобальной пользовательской базой должно иметь
быстрое соединение с пользователями, и место размещения играет важную
роль. Пограничные локации, предоставляемые CDN, помогут локализовать
расширенный контент и сократить общую задержку.
В главе 4 «Паттерны проектирования архитектур решений» вы узнали, как использовать CDN для размещения данных рядом с пользователем (раздел «Построение архитектуры на базе кэша»). Существуют различные решения CDN
с обширной сетью пограничных локаций. Используйте CDN, если в приложении
много статического контента — например, если требуется предоставлять конечному пользователю большое количество графики и видео. Некоторые популярные решения CDN — Akamai, Cloudlare и Amazon CloudFront (предоставляется
облачной платформой 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), также предоставляет надежное решение граничных вычислений для бизнесов всех размеров.
Помимо социальных сетей, граничные вычисления применяются и в других
отраслях. Например, в беспилотных автомобилях граничные устройства обрабатывают данные от датчиков в реальном времени, чтобы решения принимались за
доли секунды. Таким образом обеспечивается безопасность на дороге. В мире IoT
граничные вычисления позволяют умным устройствам анализировать данные
локально, сокращая задержку и экономя пропускную способность канала связи.
Например, умный термостат может регулировать температуру на основании
данных локальных датчиков без необходимости постоянного обмена данными
с централизованными серверами.
Выбор технологии для оптимизации производительности
267
В области здравоохранения граничные вычисления используются для дистанционного наблюдения за пациентами. Носимые устройства, оснащенные функциональностью граничной обработки, могут анализировать данные в реальном
времени и при возникновении отклонений отправлять оповещения медицинским
организациям или самим пациентам для своевременного вмешательства.
За счет смещения вычислений ближе к источникам данных и конечным пользователям граничные вычисления повышают производительность, отзывчивость
и масштабируемость, вследствие чего эта технология играет важную роль для
улучшения производительности приложения.
Рассмотрим теперь некоторые стратегии маршрутизации DNS для достижения
низкой задержки при глобальном развертывании приложения.
Определение стратегии маршрутизации DNS
Приложение можно развернуть в нескольких географических регионах, чтобы
обеспечить глобальный охват. Что касается пользовательских запросов, их
необходимо маршрутизировать к самому близкому и быстрому доступному
серверу для получения быстрого ответа от приложения. Маршрутизатор DNS
обеспечивает преобразование между доменными именами и IP-адресами. Таким
образом обеспечивается обслуживание запросов правильным сервером, когда
пользователь вводит доменное имя, — например, при вводе адреса amazon.
com в браузере запрос всегда направляется сервису DNS сервера приложения
Amazon.
y
y
y
y
AWS предоставляет сервис DNS, который называется Amazon Route 53.
В нем можно определять политики маршрутизации в зависимости от потребностей приложения. Amazon Route 53 предоставляет сервисы DNS для
упрощения управления доменом. Перечислим некоторые распространенные
политики маршрутизации.
y Простая политика маршрутизации: как подсказывает название, это самая
прямолинейная политика маршрутизации, без условий. Иногда бывает полезно маршрутизировать трафик к одному ресурсу — например, веб-серверу,
используемому для отправки информации конкретному сайту.
y Политика маршрутизации для обработки отказов: эта политика требует обеспечить высокую доступность путем настройки конфигурации обработки отказов «активный — пассивный». Если приложение выходит из строя в одном
регионе, то весь трафик автоматически перенаправляется в другой регион.
y Политика маршрутизации с учетом геолокации: если пользователь относится к конкретному региону, можно воспользоваться политикой с учетом
геолокации. Она направляет трафик в конкретный регион.
y Политика маршрутизации с учетом географической близости: имеет много
общего с политикой с учетом геолокации, но трафик может перемещаться
в ближайшие местоположения в случае необходимости.
268
Глава 6. Факторы производительности
y
y Политика маршрутизации на базе задержки: если приложение работает
y
в нескольких регионах, можно воспользоваться политикой на базе за
держки для обслуживания трафика из региона, в котором задержка наименьшая.
y Взвешенная политика маршрутизации: используется для A/B-тестирования,
когда определенная часть трафика должна направляться в отдельный регион
и расширяться по мере успешности тестирования.
Также Amazon Route 53 может обнаруживать аномалии в источнике и объеме
запросов DNS и назначать повышенный приоритет запросам от заведомо на
дежных пользователей. Кроме того, этот сервис защищает приложение от
DDoS-атак.
После прохождения через сервер DNS в большинстве случаев далее трафик проходит через балансировщик нагрузки, который распределяет трафик по кластеру
серверов. Балансировщики нагрузки рассматриваются в следующем разделе.
Применение балансировщика нагрузки
y
y
Балансировщики нагрузки распределяют сетевой трафик между серверами для
повышения конкурентности, надежности и уменьшения задержки. Балансировщики нагрузки могут быть физическими или виртуальными и должны соответствовать потребностям приложения. Обычно в приложениях используются
два типа балансировщиков.
y Сетевой балансировщик нагрузки (балансировщик нагрузки 4-го уровня):
маршрутизирует пакеты на основании информации из заголовка пакета —
например, IP-адресов и портов источника/приемника. Балансировщик нагрузки уровня 4 не анализирует содержимое пакета, вследствие чего требует
менее интенсивных вычислений, чем балансировщик нагрузки 7-го уровня
(уровня приложения), и потому работает быстрее. Сетевой балансировщик
нагрузки может обрабатывать миллионы запросов в секунду.
y Балансировщик нагрузки приложения (балансировщик нагрузки 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. Факторы производительности
Рис. 6.6. Конфигурация автомасштабирования
В этом разделе вы узнали о различных сетевых компонентах, которые помогают
улучшить производительность приложения. Сетевой трафик приложения можно
оптимизировать с учетом местоположения пользователя и потребностей приложения. Так как мобильные интерфейсы становятся основными для многих
приложений, следует проводить проактивный мониторинг производительности
мобильных приложений, чтобы повысить качество взаимодействия с пользователями. Теме факторов производительности для мобильных приложений
посвящен следующий раздел.
Факторы производительности для мобильных приложений
271
Факторы производительности для мобильных
приложений
Мобильные приложения стали неотъемлемой частью многих цифровых платформ. В наше время пользователи чаще заходят в мобильное приложение, а не
на сайт с десктопного компьютера. Более того, значительная часть пользовательского трафика приходится именно на мобильные приложения, поэтому очень
важно позаботиться о том, чтобы они имели высокую производительность. Так
как мобильные приложения превращаются в основу наших цифровых взаимодействий, приоритетом становится обеспечение их производительности, безопасности и удобства использования. Рассмотрим некоторые лучшие практики
разработки эффективных мобильных приложений.
Оптимизация времени загрузки
В мобильных приложениях время загрузки становится критически важным
фактором, который способен как повысить вовлеченность пользователей, так
и, наоборот, разочаровать их. Быстрая и эффективная загрузка чрезвычайно
важна, особенно если вспомнить, что пользователи чаще используют приложения на ходу и ожидают ответа немедленно. Некоторые способы сокращения
времени загрузки основаны на оптимизации размеров изображений, применении
отложенной загрузки элементов и ускорении загрузки изначально видимых
элементов.
Эффективное использование ресурсов
Ограниченность ресурсов (процессора, памяти, заряда батареи) означает ограниченность потенциала мобильных устройств. Чтобы приложение работало плавно
и не расходовало ресурсы устройства, разработчики должны сознательно свести
к минимуму использование ресурсов. Для этого существуют разные стратегии:
эффективные алгоритмы, сокращение утечек памяти за счет управления выделением памяти и оптимизация запросов для выборки только необходимых данных.
Отзывчивость пользовательского интерфейса (UI)
Пользовательский интерфейс должен быть интуитивно понятным и отзывчивым,
чтобы пользователь при вводе данных немедленно получал обратную связь. Для
этого любой процесс с интенсивными вычислениями (например, получение
данных или обработка изображений) должен выполняться в фоновом режиме,
чтобы он не препятствовал UI-взаимодействиям. Применение асинхронного
программирования и многопоточности сохранит адаптивность и отзывчивость
пользовательского интерфейса.
272
Глава 6. Факторы производительности
Эффективность сети
С учетом потенциала нестабильных или медленных сетевых подключений в мобильных средах приложение должно эффективно управлять сетевыми запросами.
Реализация кэширования для данных, которые изменяются нечасто, оптимизация вызовов API и корректная обработка сетевых сбоев с предоставлением
соответствующей обратной связи пользователю могут значительно улучшить
впечатления пользователя и производительность приложения.
Расход заряда батареи
Приложение, которое интенсивно расходует заряд батареи, быстро перестает
привлекать пользователей. Необходимо учитывать процессы оптимизации
и управление фоновыми задачами для минимизации потребления энергии. Следите за тем, чтобы GPS, Bluetooth и другие процессы, интенсивно расходующие
заряд, использовались разумно и отключались, когда они не нужны.
Кросс-платформенная совместимость
На рынке представлены самые разные устройства, операционные системы и размеры экранов, поэтому приложение должно поддерживать высокую производительность на разных платформах. Использование фреймворков кросс-платформенной
разработки и тщательное тестирование приложения на разных устройствах
обеспечит последовательное и оптимальное взаимодействие с пользователями.
UX-дизайн
Бесшовное и интуитивное взаимодействие с пользователем (UX, User
eXperience) — ключевой фактор успеха любого приложения. UX включает
дизайн, ориентированный на пользователя, обеспечение простоты навигации
и поддержание логики операций в приложении, чтобы пользователи могли
выполнять нужные действия с минимальными усилиями.
Эффективное управление данными
Чтобы пользователи могли получать актуальную информацию без ущерба для
производительности, важно обеспечить эффективное управление данными за
счет выбора локального хранилища для часто используемых данных, а также
бесшовную синхронизацию между локальными данными и данными, получаемыми дистанционно.
Тестирование и контроль качества
Реализация жестких протоколов тестирования, включающих тестирование производительности в разных условиях и на разных устройствах, гарантирует, что приложение сможет обеспечить оптимальную производительность даже при высокой
Тестирование производительности
273
нагрузке. Применение автоматизированного тестирования и непрерывной интеграции может помочь выявить и быстро исправить проблемы на этапе разработки.
Конструирование высокопроизводительных мобильных приложений подразу
мевает гармоничное сочетание ориентированности на пользователя и технической компетенции. Тщательно оптимизируя каждую грань приложения, от
интерфейса и времени загрузки до управления данными и средств безопасности,
разработчики могут добиться того, что приложение будет хорошо работать
в разных условиях и на разных устройствах. При реализации разных стратегий
для улучшения производительности приложения всегда рекомендуется их тщательно тестировать. В следующем разделе тестирование производительности
рассматривается более подробно.
Тестирование производительности
Тестирование производительности — важнейший тип тестирования программных
продуктов, проверяющий, что приложение будет хорошо работать при разных
рабочих нагрузках. Центральное место в нем занимает оценка стабильности, скорости, отзывчивости и масштабируемости приложения в разных условиях. Тестирование производительности не выявляет ошибки или дефекты; оно определяет,
как приложение будет реагировать на разные уровни потребностей. А с учетом
того, что современные пользователи привыкли к плавным и быстрым приложениям, тестирование производительности еще никогда не было столь важным.
Трудно переоценить, насколько в цифровую эпоху важна эффективная работа
приложений. Прежде всего она напрямую влияет на удовлетворенность пользователя. Заторможенность или частые сбои могут отбить интерес к приложению. Никто не захочет тратить время на приложение, которое не может быстро выдавать
результат, особенно при высокой нагрузке или во время пиков использования.
Неудовлетворенность в таких случаях может привести к тому, что пользователь
полностью откажется от вашего продукта и отдаст предпочтение конкурентам.
Представьте популярный интернет-магазин, который готовится к «черной
пятнице». На сайт придут тысячи, если не миллионы потенциальных покупателей, поэтому очень важно позаботиться о том, чтобы система работала без
сбоев, транзакции обрабатывались быстро, а пользовательские взаимодействия
оставались гладкими даже при пике посещений. В данном случае тестирование
производительности не просто полезно, а необходимо.
Виды тестирования производительности
y
Для каждого из параметров производительности существует своя разновидность
тестирования. Ниже приведена их краткая сводка.
y Нагрузочное тестирование: эта разновидность тестирования дает представление о том, как система поведет себя под ожидаемыми, реальными нагрузками. Его можно сравнить с тестированием моста, на который постепенно
274
Глава 6. Факторы производительности
y
y
y
y
добавляется вес, пока он не достигнет предполагаемого максимального
количества автомобилей. Например, если сайт интернет-магазина ожидает
10 000 посетителей во время праздничной распродажи, нагрузочное тестирование должно имитировать эти 10 000 посетителей, чтобы проверить, что
сайт будет нормально работать в таких условиях.
y Стрессовое тестирование: представьте, что вы втиснули в лифт нескольких
человек, превысив его допустимую нагрузку, чтобы узнать, будет он работать или сломается. В этом заключается суть стрессового тестирования. Оно
должно довести системы до предельных значений и проверить, что даже
в худших сценариях сбои не приведут к катастрофическим последствиям.
Например, банковское приложение необходимо подвергнуть стрессовому
тестированию, чтобы узнать, как оно себя поведет, если в него попытаются
одновременно войти 1 000 000 пользователей (что значительно превышает
обычный трафик).
y Тестирование на выносливость: эта разновидность тестирования отвечает на
вопрос, сможет ли система эффективно работать под ожидаемой нагрузкой
в течение продолжительного времени. Например, потоковый сервис можно
подвергнуть тестированию на выносливость, чтобы убедиться, что он способен
все выходные непрерывно транслировать фильмы и сериалы в потоковом
режиме без снижения качества или скорости.
y Пиковое тестирование: в реальных условиях пользовательский трафик может
быть непредсказуемым. Пиковое тестирование можно сравнить с проверкой
того, как поведет себя электросеть, если во время жары все пользователи
вдруг одновременно включат кондиционеры. Например, пиковое тестирование может проверять поведение новостного сайта, если во время крупного
мероприятия (скажем, Олимпийских игр) множество пользователей начнут
проверять итоги футбольного матча.
y Объемное тестирование: в этом виде тестирования первоочередное внимание
уделяется данным. Его можно сравнить с проверкой того, насколько хорошо
библиотека справится с упорядочением и выдачей миллионов книг. Для приложения с базой данных объемное тестирование может проверять поведение
системы, если в базе данных хранятся миллиарды записей. Другой пример —
проверка глобальным сервисом электронной почты отзывчивости своей
системы при поиске по колоссальному количеству хранимых сообщений.
Существует много программных инструментов тестирования производительности — например, JMeter, LoadRunner и WebLoad. Эти системы имитируют различные сценарии и нагрузки для тестирования производительности приложения.
Тестирование производительности играет важнейшую роль в жизненном цикле
разработки. Проверка отказоустойчивости, надежности и скорости приложения
критична для его успешной работы в реальных условиях.
Тестирование и мониторинг производительности — два важнейших аспекта
обеспечения эффективности и надежности приложения, но они служат разным
Мониторинг производительности
275
целям на стадиях разработки и развертывания. Тестирование производительности предназначено для выявления потенциальных проблем с производительностью до того, как они повлияют на пользователей, тогда как мониторинг
производительности обеспечивает контроль за производительностью системы
и быстрый отклик на любые проблемы, возникающие после развертывания.
Мониторинг производительности более подробно рассматривается в следующем разделе.
Мониторинг производительности
Мониторинг производительности особенно важен для проактивного предотвращения возможных последствий проблем с производительностью для конечного
пользователя.
Определите эталонный показатель производительности и настройте отправку
оповещений команде в случае его нарушения — например, время загрузки мобильного приложения не должно превышать трех секунд. Оповещение должно
инициировать автоматизированное ответное действие на проблему с недостаточно эффективными компонентами — например, добавление дополнительных
узлов в кластер веб-приложения для снижения запросной нагрузки.
Существуют разные средства мониторинга, которые измеряют производительность приложения и инфраструктуры в целом. Вы можете воспользоваться
сторонними инструментами (например, Splunk) или предоставляемым AWS
сервисом Amazon CloudWatch для мониторинга любого приложения.
y
y
Решения мониторинга можно разделить на две категории — для активного
и пассивного мониторинга.
y При активном мониторинге вы имитируете пользовательскую активность
и выявляете нехватку производительности заранее. Данные приложений и рабочая нагрузка постоянно изменяются, требуя непрерывного упреждающего
мониторинга. Активный мониторинг работает наряду с пассивным, когда
вы запускаете известные возможные сценарии для воспроизведения пользовательских взаимодействий. Активный мониторинг должен проводиться
во всех средах разработки, тестирования и эксплуатации для обнаружения
любых проблем, прежде чем они появятся у пользователя.
y Пассивный мониторинг выявляет неизвестные закономерности в реальном
времени. Для приложений на базе веб-технологий пассивный мониторинг
подразумевает получение у браузера важнейших метрик, которые могут
указывать на проблемы с производительностью. Это метрики, связанные
с геолокацией пользователей, типами браузеров и устройств, которые
помогают понять пользовательские взаимодействия и географическую
эффективность. Мониторинг основан на работе с данными и включает
такие процессы, как поглощение, обработка и визуализация больших
объемов данных.
276
Глава 6. Факторы производительности
Производительность никогда не дается даром, и вы, как архитектор решения,
должны продумать возможные компромиссы, чтобы выбрать правильный подход.
Внутренние приложения организации (скажем, продукты для учета рабочего
времени и для потребностей отдела управления персоналом) могут не требовать
такой высокой производительности, как внешние продукты (например, приложения интернет-магазинов). С другой стороны, приложение для биржевой
торговли требует очень высокой производительности, что приводит к большим
затратам. Старайтесь соблюдать баланс надежности, согласованности, затрат
и производительности, соответствующий потребностям вашего приложения.
В дальнейших главах мы продолжим изучать методы и инструменты мониторинга, а в главе 8 «Факторы надежности архитектуры» подробнее поговорим
о мониторинге и оповещениях.
Отслеживание и повышение производительности — сложные задачи, для которых приходится собирать огромное количество данных и анализировать закономерности. Закономерности доступа позволяют принять правильное решение
в части оптимизации производительности. Применение непрерывного активного
мониторинга в сочетании с пассивным мониторингом помогает поддерживать
стабильную производительность приложений.
Итоги
В этой главе вы узнали о принципах архитектурного проектирования, влияющих
на производительность приложений. Мы рассказали о задержке и пропускной
способности на разных уровнях архитектуры и о том, как связаны эти характеристики.
Для высокопроизводительных приложений необходимо обеспечить низкую
задержку и высокую пропускную способность на каждом уровне архитектуры.
Конкурентность помогает обрабатывать большое количество запросов. Вы
узнали, чем параллелизм отличается от конкурентности, и получили представление о том, как кэширование помогает улучшить общую производительность
приложения.
Затем мы обсудили, как выбрать технологию и ее рабочие модели, обеспечивающие желаемую производительность приложения. При рассмотрении возможных
вычислительных ресурсов были описаны типы процессоров и различия между
ними, которые помогают принять правильное решение при выборе экземпляров
серверов. Мы поговорили о контейнерах и о том, как они помогают эффективно использовать ресурсы и в то же время повышают производительность. Вы
также узнали, как Docker и Kubernetes работают совместно и какое место они
занимают в архитектурах.
В разделе, посвященном выбору технологии хранения, были рассмотрены
разные виды хранилищ (блоковые, файловые, объектные) и различия между
ними, а также доступные варианты хранения в локальных и облачных средах.
Итоги
277
В разделе, посвященном выбору базы данных, вы узнали о различных типах баз
данных, включая реляционные и нереляционные БД, а также информационные
хранилища. Также были представлены различные стратегии маршрутизации
запросов, которые помогают снизить сетевую задержку для пользователей из
разных геолокаций. Мы обсудили, как балансировщики нагрузки и автомасштабирование помогают обслуживать множество пользовательских запросов
без ущерба для производительности приложения. Так как для любых проектов
важны мобильные версии, мы описали факторы производительности для мобильных приложений. Мы подчеркнули, как важно проводить тестирование
производительности и мониторинг приложений, чтобы получать информацию
о производительности.
В следующей главе вы узнаете, как защитить приложения с помощью аутентификации и авторизации. Эти механизмы обеспечивают защиту данных как при
хранении, так и при передаче, а также защиту приложения от всевозможных угроз
и атак. Также мы раскроем такие темы, как аудит безопасности, оповещения,
мониторинг и автоматизация.
ГЛАВА 7
ФАКТОРЫ БЕЗОПАСНОСТИ
Безопасность всегда занимает центральное место в дизайне архитектуры. Многие
предприятия терпят убытки из-за брешей в безопасности, ведущих к утечкам
клиентских данных. В таких ситуациях можно потерять не только доверие
клиентов, но и весь бизнес.
Существует множество отраслевых стандартов и нормативов, призванных гарантировать, что приложение безопасно, а конфиденциальные данные защищены.
В предыдущей главе вы узнали о возможностях повышения производительности
и выборе подходящей технологии для архитектуры. В этой главе будут рассмотрены лучшие практики защиты приложений и обеспечения его соответствия
отраслевым стандартам.
Безопасность в архитектуре означает не только защиту границ рабочей ИТнагрузки. Необходимо также позаботиться о том, чтобы разные части инфраструктуры приложения были защищены друг от друга. Например, на сервере
можно использовать файрвол, который будет управлять тем, какие данные могут
входить в систему или выходить из нее и куда эти данные могут направляться.
При таком подходе возникновение проблем безопасности в одной части не повлияет на другие. То же самое необходимо сделать для других частей, включая
данные и программы. Безопасность должна применяться на каждом уровне и для
каждого компонента архитектуры.
Мы поговорим также о защите облачных систем.
y
y
y
y
y
В этой главе рассматриваются следующие практики безопасности.
y Принципы проектирования безопасной архитектуры.
y Выбор технологии для безопасности архитектуры.
y Безопасность и сертификация соответствия.
y Модель общей ответственности за безопасность в облаке.
y Моделирование угроз безопасности.
Принципы проектирования безопасной архитектуры
279
Принципы проектирования
безопасной архитектуры
Принципы безопасности служат для защиты системы и информации при предоставлении коммерческой ценности клиентам. Недостаточный уровень безопасности может серьезно отразиться на клиентах и бизнесе.
Для непрерывного ведения бизнеса необходимо провести углубленную оценку
рисков безопасности и спланировать стратегию их снижения. В следующих
разделах будут рассмотрены стандартные принципы проектирования, которые
способствуют укреплению безопасности архитектуры.
Аутентификация и авторизация
Цель аутентификации — определить, может ли пользователь получить доступ
к системе с предоставленными регистрационными данными, тогда как авторизация определяет, что может делать пользователь после входа в систему.
Создайте централизованную систему для управления аутентификацией и авторизацией пользователей. Централизованная система управления пользователями помогает отслеживать их операции, чтобы вы могли деактивировать
пользователей, когда они перестают быть частью системы или начинают делать
что-то неправомерное. Можно определить стандартные процедуры создания
нового пользователя и лишения доступа для неактивных пользователей. Централизованная система устраняет зависимость от учетных данных с длительным
сроком действия и позволяет настроить другие методы безопасности — такие,
как ротация паролей.
Авторизацию следует строить по принципу наименьших привилегий — он
означает, что пользователи изначально не имеют никаких прав доступа и им
назначаются только те типы доступа, которые необходимы для выполнения
ими своей работы. Создание групп доступа в соответствии с рабочими ролями
позволяет управлять политикой авторизации в одном месте и применять ограничения авторизации к большому количеству пользователей. Например, можно предоставить группе разработки полный доступ к среде разработки и доступ
только для чтения к рабочей среде. Если в компании появляется новый разработчик, он должен быть добавлен в группу разработки, где осуществляется
централизованное управление всеми политиками авторизации.
Включение системы единого входа (SSO, Single Sign-On) с централизованным
репозиторием пользователей избавляет от необходимости хранить множество
паролей для пользовательской базы и устраняет риск утечки паролей. Интеграция многофакторной аутентификации (MFA, multi-factor authentication) с SSO
добавляет дополнительный уровень защиты. По условиям MFA пользователь
должен предъявить два и более доказательства верификации (маркер безопасности, отпечаток пальца, распознавание лица и т. д.), чтобы получить доступ
к ресурсу.
280
Глава 7. Факторы безопасности
Большие организации используют централизованные средства управления
пользователями (такие, как Active Directory) в целях аутентификации и авторизации сотрудников для предоставления доступа к внутренним корпоративным
приложениям: системам управления персоналом, учета затрат, учета рабочего
времени и т. д.
В приложениях, обращенных к клиенту, — например, интернет-магазинах
и сайтах социальных сетей — можно использовать систему аутентификации
OpenID для управления централизованной системой. OpenID — протокол
аутентификации, основанный на открытых стандартах.
Повсеместное применение безопасности
Часто организации направляют основные усилия на обеспечение физической
безопасности дата-центров и защиту внешнего сетевого уровня от атак. Не ограничивайтесь внешним уровнем и позаботьтесь о том, чтобы безопасность применялась на каждом уровне приложения.
Применяйте принцип защиты в глубину (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. Факторы безопасности
Создавайте защищенные архитектуры и реализуйте средства безопасности,
которые определяются и управляются так же, как код. Можно использовать
средства безопасности с системой контроля версий и анализировать изменения
по мере необходимости. Автоматизированные механизмы безопасности в форме
программного кода предоставляют возможность более быстрого и экономичного
масштабирования операций безопасности.
Защита данных
Данные занимают центральное место в архитектуре, поэтому их защита чрезвычайно важна. Большинство действующих нормативов безопасности предназначено для защиты клиентских и идентификационных данных. Значительная
часть атак направлена на похищение пользовательских данных.
Классифицируйте данные по уровню безопасности и защитите их соответ
ствующим образом. Например, информация о кредитной карте клиента относится
к самым чувствительным данным, и работать с ней необходимо с исключительной
осторожностью. А такие данные, как имя клиента, не настолько секретны и не
требуют самого высокого уровня защиты.
y
y
y
Защита данных на протяжении их жизненного цикла чрезвычайно важна для
поддержания их конфиденциальности, целостности и доступности. Данные могут
существовать в трех состояниях, причем каждое из них требует конкретных мер
безопасности для обеспечения комплексной защиты.
y Хранимые данные: данные, хранящиеся на физическом носителе (жестком
диске сервера, ноутбуке, USB-накопителе или в облачном хранилище).
Один из возможных механизмов защиты для хранимых данных — шифрование — гарантирует, что, даже если носитель попадет в посторонние
руки, данные останутся недоступными без ключа шифрования. Кроме
того, необходимо установить средства управления доступом и регулярно
проводить аудиты, чтобы к данным могли обращаться только авторизованные пользователи.
y Передаваемые данные: данные, перемещающиеся по сети (с компьютера
пользователя на сервер, между серверами или в интернете). Чтобы защитить данные при передаче, можно воспользоваться такими протоколами
шифрования, как TLS (Transport Layer Security). Эта мера гарантирует, что,
даже если данные будут перехвачены в ходе передачи, атакующий не сможет
прочитать их.
y Используемые данные: часто защита этого состояния сложнее всего, потому
что данные обрабатываются или используются приложениями. Шифрование
может защищать данные при хранении и передаче, но данные, загруженные
в память и используемые приложением, хранятся в виде простого текста и потенциально уязвимы. Сейчас появляются новые технологии защиты используемых данных — например, TEE (Trusted Execution Environment — доверенная
Выбор технологий для безопасности архитектуры
283
среда выполнения) и гомоморфное шифрование. Они позволят выполнять
операции с зашифрованными данными без их предварительного дешифрования.
Создайте механизмы и инструменты, минимизирующие необходимость в прямых
обращениях к данным. Избегайте ручной обработки данных за счет применения
инструментальной автоматизации, исключающей человеческие ошибки, особенно при работе с конфиденциальными данными. Применяйте ограничения
доступа к данным там, где это возможно, для сокращения риска потери или
модификации данных.
После классификации данных по уровню конфиденциальности можно воспользоваться необходимыми средствами шифрования, выделения базовых элементов
и управления доступом для защиты данных. Данные должны защищаться не
только при хранении, но и при передаче по сети. Различные механизмы защиты
данных также будут рассмотрены в разделе «Безопасность данных» этой главы.
Ответ на инциденты безопасности
Будьте готовы к любым происшествиям в области безопасности. Создайте процесс управления инцидентами как часть требований политики организации.
Управление инцидентами может различаться в зависимости от организации
и приложения. Например, если приложение работает с персональной информацией клиентов (PII, personally identifiable information), ответ на инциденты
безопасности потребует более жестких мер безопасности. С другой стороны,
если приложение обрабатывает небольшие объемы чувствительных данных
(например, приложение учета складских запасов), то в нем можно использовать
другой подход.
Обязательно смоделируйте инцидент, чтобы увидеть, как будет на него реагировать ваша команда безопасности. Она должна использовать средства автоматизации для ускорения обнаружения, анализа и ответа на любые происшествия
безопасности. Выработайте механизмы оповещений, мониторинга и аудита для
анализа первопричин, чтобы инциденты не повторялись.
В этом разделе вы узнали об общих принципах безопасности, которые необходимо соблюдать в архитектуре для безопасности приложения. В следующем разделе
вы узнаете, как применять эти принципы с разными инструментами и методами.
Выбор технологий для безопасности
архитектуры
В предыдущем разделе основное внимание уделялось общим правилам безопасности, которые необходимо учитывать при проектировании архитектуры.
Тем не менее остается важный вопрос: как применять эти правила, чтобы обес
печить безопасность приложения во время его реальной работы? Существуют
284
Глава 7. Факторы безопасности
различные инструменты и методы для каждого уровня приложения, которые
помогут сделать его безопасным.
В этом разделе подробно рассматриваются разные варианты технологий из
области управления пользователями и защиты веб-уровня, инфраструктуры
и данных приложения. Начнем с идентификационных данных пользователей
и управления доступом.
Идентификационные данные пользователей
и управление доступом
Идентификационные данные пользователей и управление доступом — важнейшие параметры информационной безопасности. Это объясняется тем, что
доступ к ресурсам системы должны получать только пользователи, прошедшие
авторизацию и аутентификацию.
Управление пользователями может стать непростой задачей с ростом организации и расширением пользовательской базы продукта. Механизм управления
пользовательским доступом должен различать сотрудников организации, поставщиков и клиентов и управлять доступом для каждой категории.
К категории корпоративных пользователей могут относиться сотрудники организации, подрядчики или поставщики. Это пользователи-специалисты с особыми привилегиями разработки, тестирования и развертывания приложения.
Кроме того, им может понадобиться доступ к другим корпоративным системам
для выполнения повседневной работы — например, к системе управления ресурсами предприятия (ERP, Enterprise Resource System), системе начисления
заработной платы, управления персоналом, приложению учета рабочего времени и т. д. С ростом организации количество пользователей может возрасти
от сотен до тысяч.
Конечными пользователями являются клиенты, которые используют приложения и обладают доступом для исследования и практического применения нужной
функциональности — например, игроки в игровом приложении, пользователи
в приложении социальной сети или покупатели на сайте интернет-магазина.
С ростом популярности продукта количество таких пользователей может исчисляться тысячами и даже миллионами. Установите особые меры безопасности
при открытии приложению доступа к внешнему интернет-трафику, чтобы защитить приложение от угроз.
Начнем с управления корпоративными пользователями. Вам понадобится
централизованный репозиторий для соблюдения таких политик безопасности,
как создание надежных паролей, ротация паролей и MFA для улучшенного
управления пользователями. MFA предоставляет дополнительные средства
проверки личности пользователя, если пароль мог быть взломан. Среди популярных поставщиков MFA можно выделить Google Authenticator, Gemalto,
YubiKey, RSA SecurID, 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.
Клиент
Сервер аутентификации
Сервер выдачи тикетов
Сервер
Запрос TGT
TGT и ключ сессии
Запрос тикета сервиса с TGT
Тикет сервиса
Обращение к сервису с тикетом
Предоставление доступа
Клиент
Сервер аутентификации
Сервер выдачи тикетов
Сервер
Рис. 7.3. Аутентификация Kerberos
Как видно из диаграммы, обращение к сервису подразумевает серию шагов.
1. Когда вы обращаетесь к сервису в своей компьютерной сети, ваш компьютер
(клиент) запрашивает тикет у специального сервиса, который называется
сервером аутентификации (AS, Authentication Server).
2. Сервер AS проверяет, присутствуете ли вы в его базе данных. Если ваши
данные найдены, он создает тикет выдачи тикета (TGT, Ticket-Granting
Ticket), а также ключ сессии, и отправляет их вашему компьютеру. Вы
можете разблокировать ключ сессии своим паролем, но разблокировать
TGT не удастся, потому что он заблокирован ключом, имеющимся только
у TGS.
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 представлена простая схема процесса аутентификации.
Active Directory
1. Пользователь вводит удостоверения доступа.
Устройство
пользователя
2. AD проверяет пользовательские удостоверения
и возвращает маркер аутентификации.
3. Маркер доступа, предоставленный
пользователю для поддержания сессии.
Сервис
Рис. 7.4. Аутентификация AD
Как видно из рис. 7.4, входом пользователя управляет AD в сетях домена. Пользователь сначала отправляет запрос контроллеру домена со своими удостоверениями и взаимодействует с Active Directory Authentication Library (ADAL).
ADAL проверяет удостоверения и возвращает маркер доступа с непрерывной
сессией для запрашиваемого сервиса.
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 позволяет включить поддержку MSA посредством интеграции
с существующей инфраструктурой 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.
Удостоверения, отправленные
для проверки
База данных пользователей
Экран входа
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) и OpenID
подходят лучше, чем SAML. В следующих разделах более подробно рассматриваются OAuth и OIDC (OpenID 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. Пользователь отправляет запрос к приложению LinkedIn на получение фотографии для профиля из Facebook.
292
Глава 7. Факторы безопасности
2. Приложение LinkedIn запрашивает авторизацию для обращения к фотографиям пользовательского профиля в Facebook.
3. Сервер авторизации (в данном случае учетная запись пользователя в Facebook)
создает и выводит для пользователя экран подтверждения согласия.
4. Пользователь дает согласие на запрос к приложению LinkedIn для обращения
только к фотографиям в его профиле Facebook.
5. После получения одобрения сервер авторизации Facebook отправляет код
авторизации запрашивающему приложению LinkedIn.
6. Приложение LinkedIn запрашивает маркер авторизации от сервера авторизации (учетной записи Facebook) с использованием кода авторизации.
7. Сервер авторизации идентифицирует приложение LinkedIn и проверяет
действительность кода авторизации. Если код проходит проверку, сервер
выдает маркер доступа приложению LinkedIn.
8. Приложение LinkedIn теперь может обращаться к таким ресурсам, как фотографии из профиля Facebook, с использованием маркера доступа.
Пользователь
Сервер авторизации
(Facebook)
Приложение
LinkedIn
FaceBook
Запрос для получения фотографии в профиле
Запрос авторизации для обращения к фотографиям
Отображение экрана для подтверждения согласия
Предоставление согласия
Отправка кода авторизации
Запрос маркера доступа с использованием кода авторизации
Проверка кода и выдача маркера доступа
Обращение к фотографиям в профиле с маркером доступа
Пользователь
Приложение
LinkedIn
Сервер авторизации
(Facebook)
FaceBook
Рис. 7.6. Делегирование пользовательского доступа с OAuth 2.0
Примечание. В наше время чаще используется версия OAuth 2.0, которая
работает быстрее OAuth 1.0 и более удобно реализуется.
В следующем разделе рассмотрим JWT (JSON Web Token) — простой и доступный формат маркера, который может использоваться с OAuth и пользуется
популярностью с OpenID.
Выбор технологий для безопасности архитектуры
293
JWT
JWT — компактный и автономный механизм безопасной передачи информации
между сторонами в виде объекта JSON. Эту информацию можно проверить,
и ей можно доверять, потому что она снабжается цифровой подписью. Маркеры
JWT могут подписываться с использованием секрета или пары из открытого/
закрытого ключа.
JWT имеет структуру JSON с информацией о времени прекращения действия,
источнике, теме и т. д. Он надежнее SWT (Simple Web Token) и проще SAML 2.0.
Структура JWT представлена на рис. 7.7.
Рис. 7.7. Пример JWT
На скриншоте вы видите маркер JWT из трех частей, разделенных точками. Первая часть (заголовок) указывает на тип маркера (JWT) и алгоритм, используемый
для цифровой подписи (например, HS256 или RSA). Вторая часть (полезная
нагрузка) содержит утверждения — блоки информации о пользователе и другие
данные. Последняя часть содержит цифровую подпись, которая гарантирует,
что маркер не был изменен, и подтверждает отправителя JWT.
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 на парки серверов и перегружать их выполнением
бессмысленных операций.
y
y
На уровне инфраструктуры типичная DDoS-атака выполняется по следующим
схемам:
y отражение UDP (User Datagram Protocol): при отражении UDP атакующий
фальсифицирует IP-адрес целевого сервера и выдает запрос, который возвращает большой объем ответов от взломанного сервера-«отражателя»;
y SYN-флуд: атакующие блокируют работу сервиса TCP (Transmission Control
Protocol) целевого сервера, создавая и оставляя большое количество подключений, не позволяя легитимным пользователям получить доступ к серверу.
Часто атакующие пытаются похитить конфиденциальные данные клиентов. Для
этого они используют различные виды атак, называемые атаками внедрения
SQL, или SQL-инъекцией (SQLi, SQL injection). В следующем разделе этот
класс атак рассматривается более подробно.
Атаки SQLi
Как следует из названия, атакующие внедряют вредоносный код SQL для получения контроля над базой данных SQL и чувствительными данными пользователя.
Атакующий использует SQLi для получения несанкционированного доступа
к информации, контроля над приложением, создания новых пользователей и т. д.
Для примера возьмем приложение для обработки заявок на кредиты. В базе
данных присутствует поле loadId, которое используется клиентами для получения всей информации, относящейся к их кредиту. Если не принять должных
мер защиты, атакующий может выполнить запрос вида SELECT * FROM loans
WHERE loanId = 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-атаки.
Фундаментальный принцип обеспечения безопасности архитектуры — сокращение количества потенциальных целей, которые может поразить атакующий.
Проще говоря, если экземпляр не обязательно делать открытым, то его не нужно
делать открытым.
y
y
Существуют разные стратегии минимизации поверхности атаки.
y Там, где возможно, сокращайте количество точек входа в интернет — например, откройте входящий доступ балансировщику нагрузки, но не вебсерверам.
y Выявите и устраните все необязательные точки входа в интернет. Например,
можно создать файловое хранилище для отправки данных поставщиками, но
Выбор технологий для безопасности архитектуры
299
y
y
y
ограничить к нему доступ, чтобы он был только у небольшой группы, а не
у всего глобального интернет-трафика.
y Скройте все необходимые точки входа в интернет от ненадежных конечных
пользователей, чтобы они не могли к ним обращаться.
y Изолируйте точку доступа и примените особую политику ограничений для
трафика конечных пользователей (в отличие от трафика управления приложением).
y Создайте изолированную точку входа в интернет для минимизации поверхности атаки.
Вашей главной целью должна быть блокировка DDoS-атак на границе CDN.
Бороться с DDoS-атаками, которые доберутся до серверов приложений, будет
сложнее и затратнее. На рис. 7.9 изображен пример блокировки DDoS для рабочей нагрузки в облаке AWS.
Пользователи
Автомасштабирование
Пограничная
локация
CloudFront
ELB
WAF
ELB
Сервер
веб-приложения
Группа безопасности
DDoS
Публичная
подсеть DMZ
Частная подсеть WAF/прокси
Серверы фронтенда
Рис. 7.9. Стратегия трехслойной блокировки DDoS с использованием WAF
На диаграмме изображена трехслойная архитектура, в которой WAF размещается
между двумя балансировщиками нагрузки для блокировки DDoS-атак.
Многие DDoS-атаки строятся на таких стратегиях, как SYN-флуд и отражение
UDP. Amazon CloudFront предотвращает их, принимая только четко оформленные подключения еще до того, как атакующий сможет добраться до серверов
приложений. Некоторые CDN (такие, как Amazon CloudFront) помогают справиться с DDoS-атаками за счет того, что трафик изолируется в географически
обособленной области и не может влиять на другие области. Сетевые файрволы
помогают управлять входящим и исходящим трафиком на уровне отдельных
серверов.
Как упоминалось в предыдущем разделе, WAF используются для защиты вебприложений от таких атак, как XSS и SQLi. Кроме того, WAF помогают обнаруживать и предотвращать DDoS-атаки на уровне веб-приложения.
300
Глава 7. Факторы безопасности
Чтобы заблокировать DDoS-атаку, следует применить либо горизонтальное,
либо вертикальное масштабирование. Схема масштабирования может выглядеть
примерно так.
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/01introduction/05-introduction.
Сетевая безопасность
Когда речь заходит о защите инфраструктуры, прежде всего следует позаботиться о защите сети. Физическая безопасность ИТ-инфраструктуры в дата-центре
должна обеспечиваться его провайдерами. А ваша обязанность как владельца
приложения — думать о безопасности сети.
Пример с провайдером публичной облачной платформы — такой, как AWS — поможет лучше понять, как обеспечивается сетевая безопасность. Этот же пример
можно применить в локальной или частной облачной сетевой инфраструктуре.
302
Глава 7. Факторы безопасности
Как показано на рис. 7.10, о безопасности следует заботиться на каждом уровне,
и на каждом уровне должны быть определены границы доверия с минимальным
доступом.
Облако AWS
Шлюз Интернета
VPC
Открытая подсеть
Таблица
маршрутизации
Группа безопасности
ACL
Сетевой
список
ACL
Группа безопасности
ACL
Сетевой
список
ACL
WAF
Открытая подсеть
Таблица
маршрутизации
Шлюз NAT
Таблица маршрутизации
Группа безопасности
Парк серверов приложения
Таблица
маршрутизации
Таблица маршрутизации
Группа безопасности
Таблица
маршрутизации
Серверы баз данных
Хостбастион
ACL
Сетевой
список
ACL
ACL
Сетевой
список
ACL
Рис. 7.10. Сетевая конфигурация для безопасности инфраструктуры
На этой диаграмме балансировщик нагрузки находится в открытой подсети,
которая может принимать интернет-трафик и распределять его по парку серверов приложений. Фильтрация трафика WAF основана на заданных правилах
и защищает приложение от различных атак, как вы узнали в предыдущем разделе. Парк серверов приложений и серверы базы данных находятся в частных
подсетях, это означает, что прямой доступ к ним из интернета невозможен.
Рассмотрим эту архитектурную диаграмму подробнее, уровень за уровнем.
y
y Amazon VPC (Virtual Private Cloud) предоставляет логически изолированную
сеть для облачной инфраструктуры. VPC становится персонализированной
сетевой средой в облаке и используется для размещения ресурсов. VPC
позволяет разделять разные среды и ресурсы. Можно создать несколько
y
y
y
y
y
y
y
y
Выбор технологий для безопасности архитектуры
303
VPC в каждой учетной записи AWS или регионе. При создании VPC определяется диапазон IP-адресов с помощью записи CIDR (Classless InterDomain 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. Факторы безопасности
y
y NACL — необязательный уровень безопасности в форме виртуального файр-
y
y
y
вола, контролирующего как входящий, так и исходящий трафик на уровне
подсети. В отличие от группы безопасности, имеющей состояние, NACL
работает без сохранения состояния. Отсутствие состояния означает, что
каждый запрос, входящий или исходящий, рассматривается независимо. Например, даже если входящий запрос допустим, соответствующий исходящий
ответ также должен быть явно разрешен по правилам NACL. Это требует
тщательного определения правил как для входящего, так и для исходящего
трафика, чтобы обеспечить правильное прохождение трафика и безопасность
на уровне подсети.
y Интернет-трафик маршрутизируется через интернет-шлюз (IGW), чтобы
подсеть была открытой. По умолчанию доступ к интернету для интернет-трафика в среде запрещен. Шлюз должен быть присоединен к VPC, а в таблице
маршрутизации подсети должны быть определены правила для IGW.
y Частная подсеть блокирует весь входящий и исходящий интернет-трафик,
но исходящий трафик может потребоваться серверам для установки программ и патчей безопасности. Шлюз NAT позволяет экземплярам в частной
подсети инициировать исходящий трафик в интернет и защищает ресурсы
от входящего интернет-трафика.
y Хост-бастион работает как промежуточный сервер, предоставляющий доступ
к другим ресурсам частной подсети. Для хоста-бастиона необходимо обес
печить более жесткие меры безопасности, чтобы к нему могли обращаться
только те, кому это разрешено. При входе на сервер для аутентификации
всегда используется шифрование с открытым ключом вместо обычного метода
с идентификатором пользователя и паролем.
Организации собирают, хранят и анализируют журнальные данные по многим причинам. В частности, чтобы диагностировать сбои соединения, решать
проблемы безопасности и оценивать политики сетевого доступа. Вы должны
отслеживать поток трафика в системную сеть VPC, для чего необходимо сохранять информацию о входящем и исходящем трафике из сети. Журналы потока
трафика VPC позволяют получить эту информацию вместе с информацией
о принятом и отклоненном трафике для заданного ресурса, что помогает лучше
понять закономерности трафика.
Журналы потока трафика служат инструментом безопасности для мониторинга
трафика к экземплярам. Можно настраивать сигналы для конкретных типов трафика и создавать метрики для выявления трендов и закономерностей. Журналы
потока трафика можно вести для VPC, подсети или сетевого интерфейса. При
создании для подсети или VPC они отслеживают каждый сетевой интерфейс
в этой подсети или VPC. Представим, что у вас имеется VPC с несколькими
подсетями. Создавая журнал потока трафика для сети VPC, можно отслеживать
весь входящий и исходящий трафик через ее сетевые интерфейсы. При обнаружении аномальных закономерностей трафика (например, неожиданных пиков
Выбор технологий для безопасности архитектуры
305
в запросах данных с неизвестного IP-адреса) можно настроить оповещение. Такой
активный мониторинг помогает выявить потенциальные угрозы безопасности
или неэффективную работу сети на ранней стадии.
Как видите, на сетевом уровне доступны разные уровни безопасности, которые
помогают защитить инфраструктуру. Хранение ресурсов в изолированной
подсети помогает сократить радиус поражения. Даже если атакующий сможет
проникнуть в один компонент, должна быть возможность изолировать его ограниченным кругом ресурсов. Используйте IDS и IPS перед инфраструктурой
для обнаружения и предотвращения любого вредоносного трафика. Эта тема
рассматривается в следующем разделе.
Системы обнаружения и предотвращения вторжений
Системы обнаружения вторжений (IDS) обнаруживают кибератаки, выполняемые через сетевой трафик, посредством анализа шаблонов атак. Системы
предотвращения вторжений (IPS) идут еще дальше и стараются проактивно
остановить вредоносный трафик.
y
y
IPS предоставляет критический анализ потенциальных угроз, расположенных
за файрволом. Система IPS обнаруживает опасный контент (например, вредоносные пакеты) и блокирует трафик либо сбрасывает подключения. У IPS есть
два основных метода обнаружения:
y обнаружение на основе сигнатур: метод использует растущую базу данных
уникальных шаблонов (сигнатур), связанных со всеми известными видами
атак;
y обнаружение на основе статистических аномалий: метод устанавливает
эталон нормальной производительности сети и сравнивает с ним случайные
выборки сетевого трафика. При обнаружении значительных отклонений 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
Безопасность данных
В современном цифровом мире в центре любой системы находятся данные.
Иногда эти данные могут содержать чувствительную информацию: медицинские карты клиентов, платежную информацию, удостоверения личности и т. д.
Очень важно защитить клиентские данные, чтобы предотвратить любой несанкционированный доступ к ним. Многие отрасли уделяют особое внимание
защите данных и безопасности.
Прежде чем проектировать решение, следует определить основные практики
безопасности, сочетающиеся с поставленной целью (например, соответствие
нормативным требованиям).
Для защиты данных применяются разные методы. Они будут рассмотрены
в следующих разделах.
Классификация данных
Одна из лучших практик — классификация данных, предоставляющая возможность разделения данных на категории и обработки упорядоченных данных на
основании уровней безопасности.
В зависимости от чувствительности данных можно планировать требования
к защите данных, их шифрованию и обращению к данным.
Определяя классификацию данных в соответствии с требованиями к рабочей
нагрузке системы, можно создавать средства управления данными и необходимый уровень доступа. Например, такой контент, как пользовательские оценки
и отзывы, часто считается публичным, и открытый доступ к нему вполне допустим, но информация кредитной карты пользователя — строго конфиденциальные данные, которые необходимо шифровать и доступ к которым должен
быть максимально ограничен.
y
y
y
На высоком уровне данные можно разделить на следующие категории.
y Конфиденциальные данные (restricted) содержат информацию, которая
может нанести прямой ущерб клиенту при попадании в чужие руки. Некорректная работа с такими данными может повредить репутации компании
и отрицательно повлиять на бизнес. К конфиденциальным данным могут
относиться персональные данные клиентов (PII): номера социального
страхования, паспортные данные, номера кредитных карт, платежная
информация.
y Приватные данные (private) содержат чувствительную информацию, которой
может воспользоваться злоумышленник для похищения конфиденциальных
данных. Приватные данные могут включать адреса электронной почты клиентов, номера телефонов, полные имена и адреса.
y Публичные данные (public) открыты и доступны всем и поэтому требуют м инимальной защиты — например, оценки и отзывы клиентов,
308
Глава 7. Факторы безопасности
местонахождение клиента, ник пользователя, если пользователь решил
сделать его открытым.
Возможны и более мелкие категории в зависимости от отрасли и характера
пользовательских данных. Классификация данных должна выдерживать баланс
между удобством использования данных и контролем доступа к ним. Настройка
разных уровней доступа, как упоминалось ранее, помогает ограничивать доступ
только к необходимым данным и гарантировать защиту конфиденциальной информации. Никогда не предоставляйте пользователям прямой доступ к данным;
используйте инструменты, которые могут формировать отчеты в режиме «только
для чтения». Тем самым вы ограничите возможность несанкционированного
доступа к данным.
Шифрование данных в покое
Данные в покое (data at rest) — это данные, которые находятся в постоянном
хранилище, не передаются и не используются: например, в сети хранения данных (SAN, storage area network), на сетевом накопителе (NAS, network-attached
storage) или в облачном хранилище. Вся конфиденциальная информация должна
быть защищена применением симметричного или асимметричного шифрования
с надежным управлением ключами.
Кроме шифрования, существуют и другие методы защиты данных в покое (такие,
как маскировка и токенизация). Эти методы предоставляют дополнительные
уровни безопасности и особенно полезны в сценариях, когда необходимо использовать или передавать конфиденциальную информацию без раскрытия
самих данных.
Шифрование данных — способ защиты, при котором данные из простого текста
преобразуются в закодированный формат шифротекста при помощи ключа
шифрования. Чтобы шифротекст можно было прочитать, его необходимо расшифровать с ключом дешифрования, а ключ дешифрования доступен только
авторизованным пользователям.
y
y
Часто используемые методы шифрования на базе ключей относятся к одной из
двух криптографических категорий.
y Шифрование с симметричным ключом: в симметричных алгоритмах один
и тот же ключ используется для шифрования и дешифрования данных.
Каждый пакет данных шифруется с секретным ключом при сохранении
и дешифруется при чтении. Раньше симметричное шифрование применялось
в соответствии со стандартом DES (Data Encryption Standard), в котором
используется 56-разрядный ключ. Сейчас для симметричного шифрования
используется более надежный стандарт AES (Advanced Encryption Standard)
со 128-, 192- или 256-разрядным ключом.
y Шифрование с асимметричным ключом: в асимметричных алгоритмах
задействованы два разных ключа: один используется для шифрования,
Выбор технологий для безопасности архитектуры
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) также представляют такие
хранилища — например, AWS CloudHSM. Вы также можете выбрать поставщика
HSM самостоятельно.
HSM — специализированное устройство, спроектированное для защиты криптографических ключей и операций, представляющих защищенные механизмы
физической и логической безопасности. Оно спроектировано так, чтобы обнаруживать попытки взлома и реагировать на них стиранием ключей. На логическом
уровне HSM применяет жесткий контроль доступа, предоставляя только авторизованным пользователям конкретные роли и взаимодействия с устройством. Для
предотвращения потери данных важно обеспечить высокую доступность HSM,
обычно посредством развертывания нескольких компонентов в разных местах.
Шифрование передаваемых данных
Под «передаваемыми данными» (data in transit) имеются в виду данные, передаваемые по сети. Данные в покое (data at rest) могут шифроваться в источнике
и приемнике, но при передаче данных должен защищаться также канал, по
которому они передаются.
Когда данные передаются по незашифрованному протоколу (например, HTTP),
их можно перехватить посредством таких атак, как атака подслушиванием
(eavesdropping) или атака «человек посередине» (MIТM, 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 использует сертификаты для
передачи открытого ключа с асимметричным шифрованием, а затем открытого
ключа для передачи закрытого ключа с симметричным шифрованием. Сертификат безопасности выдается одним из центров сертификации (CA, 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 получил более широкое распространение для подключений к серверам, а 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 могут быть очень серьезными, влияющими на
доход компании, ее репутацию и правовые вопросы.
y
y
y
Ниже перечислены некоторые практики по обеспечению безопасности API.
y Аутентификация и авторизация: используйте сильные методы аутентификации (такие, как OAuth или JWT) для идентификации сущностей, пытающихся
обратиться к API. Кроме того, реализуйте эффективные протоколы авторизации для управления правами доступа. Это означает, что даже пользователи,
прошедшие аутентификацию, смогут обращаться только к тем данным или
функциям, к которым им это явно разрешено. Безопасный API знает, кто
выдает запрос и к чему этой сущности разрешено обращаться. Банковское
приложение использует API, чтобы пользователи имели возможность проверять баланс своего счета, и OAuth, чтобы только пользователи, прошедшие
аутентификацию и авторизацию, могли просматривать подробную информацию о своих счетах.
y Ограничение частоты: реализуйте ограничение частоты для предотвращения
многих злоупотреблений, включая атаки методом «грубой силы» (брутфорса).
Ограничивая количество запросов, которые могут поступить от пользователя или IP-адреса за заданный промежуток времени, можно предотвратить
перегрузку системы вследствие потенциальных атак или попытки быстрого
перебора многих комбинаций. API интернет-магазина может запретить
пользователям выдавать более 10 запросов в минуту, чтобы предотвратить
перегрузку системы и потенциальные злоупотребления.
y Проверка ввода: всегда проверяйте и проводите очистку данных, отправляемых вашему API. Тем самым вы можете предотвратить различные виды атак
(включая SQLi), при которых злоумышленник отправляет некорректные
данные в надежде манипулировать вашей системой. Представим, что форма
обратной связи в интернете использует API для отправки пользовательских
комментариев. Система проверяет, что введенные данные не содержат вредоносных скриптов, которые могут использоваться для взлома веб-сайта.
Выбор технологий для безопасности архитектуры
313
y
y
y
y
y
y
y
y
y
y Шифрование: данные, передаваемые API и возвращаемые ими, должны
шифроваться с использованием таких протоколов, как TLS. Это гарантирует,
что даже в случае перехвата пакетов данных злоумышленник не сможет их
прочесть. Приложение-мессенджер обеспечивает шифрование сообщений,
передаваемых между пользователями. Если кто-то перехватит сообщение,
он увидит только набор бессмысленных символов вместо реального содержимого. Шифрование можно сравнить с общением на условном языке. Даже
если кто-то подслушает ваш разговор, он поймет его только в том случае,
если сам владеет этим языком.
Регулярный мониторинг и аудит: непрерывно отслеживайте активность
API. Любые необычные закономерности — неожиданные пики запросов,
аномальные схемы обращений к данным — могут оказаться ранними признаками атаки или эксплуатации уязвимости. Регулярный аудит также
поможет выявить ошибки в настройках безопасности. Провайдер облачных
платформ отслеживает свои API для выявления необычных схем передачи
данных: он следит, чтобы большие объемы данных не загружались и не отправлялись неожиданно, что может указывать на взлом. Представьте камеры
видеонаблюдения в магазинах — они наблюдают за происходящим и помогают
предотвращать кражи.
Реализация шлюзов API: использование шлюзов API может стать дополнительным уровнем защиты. Шлюзы обеспечивают маршрутизацию запросов,
компоновку API и другие функции, благодаря которым до бэкенд-систем
доберутся только проверенные запросы. Сайт интернет-магазина использует
шлюз API для управления запросами, чтобы к его базе данных поступали
только легитимные и должным образом структурированные запросы, а потенциально вредоносные запросы отфильтровывались. Представьте портье
в гостинице, который проверяет и подтверждает бронь, прежде чем пропустить гостя в номер.
Обработка ошибок: избегайте раскрытия конфиденциальной информации
в сообщениях об ошибках. Пользователю должно возвращаться обобщенное
сообщение, а подробное описание должно безопасно храниться на стороне
сервера для диагностики. Когда пользователь пытается сбросить пароль,
а его адрес электронной почты не распознан системой, система не сообщает,
что адрес ошибочен или не существует. Она просто предлагает повторить
действие, предотвращая потенциальные попытки фишинга.
Использование файрволов веб-приложений: WAF могут обнаруживать
и блокировать вредоносные запросы к API, предоставляя еще один уровень
защиты от типичных веб-угроз. Например, в случае интернет-магазина WAF
может анализировать входящий трафик к конечным точкам API, выявляя
и предотвращая потенциально вредоносные запросы — такие, как атаки SQLi
и XSS. Таким образом гарантируется обработка только легитимных запросов,
а приложение защищается от киберугроз.
314
Глава 7. Факторы безопасности
y
y Версионирование: реализуйте механизм версионирования API. Если в од-
y
ной версии API будет обнаружена проблема безопасности, ее можно будет
решить без влияния на другие версии, что обеспечит непрерывность работы
сервиса для приложений, использующих другие версии. Представим, что
у вас есть мобильное приложение, которое зависит от API для получения
пользовательских данных, и вы реализовали версионирование (например,
v1, v2, v3). Если в версии v2 будет обнаружена уязвимость безопасности, вы
можете быстро решить ее в этой версии, тогда как более старая (v1) и новая
(v3) версии продолжат работать безопасно. Такой подход позволяет группе
разработки устанавливать исправления или обновления для конкретных
версий API, сводя к минимуму последствия для конечных пользователей.
y Периодическое тестирование безопасности: периодически проводите тестирование API на проникновение и оценку уязвимостей. Такой проактивный
подход позволит выявить и исправить потенциальные слабости до того, как
ими воспользуются злоумышленники. Платформа музыкального стриминга периодически тестирует свой API, чтобы убедиться, что посторонние
пользователи не смогут получить доступ к премиальным возможностям без
соответствующей подписки.
Поскольку API — ключевое звено современных цифровых инфраструктур, необходимость в их защите возрастает. Соблюдая лучшие отраслевые практики
и применяя проактивный подход, компании могут защитить свои операции,
клиентов и репутацию от возникающих угроз.
Ряд руководящих органов публикует нормативы, касающиеся безопасности
данных. Такие нормативы могут принимать форму контрольных списков с требованиями, которые необходимо соблюдать. Комплаенс также обеспечивается
соблюдением отраслевых и местных правил. Различные меры соответствия
рассматриваются в следующем разделе.
Сертификация безопасности и соответствия
y
y
Многие сертификаты соответствия, направленные на защиту конфиденциальности клиентов и безопасность данных, зависят от отрасли и географического
положения. В любом проектируемом решении требования к комплаенсу являются одними из важнейших для соблюдения. Ниже перечислены некоторые из
самых известных географических и отраслевых нормативов:
y К категории глобального соответствия относятся стандарты, которые должны
соблюдать все организации независимо от региона. К их числу принадлежат
ISO 9001, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3 и CSA
STAR для облачной безопасности.
y Правительство США требует соблюдения различных нормативов для работы
в государственном секторе. В частности, стандартов FedRAMP, DoD SRG
Level-2, 4 и 5, FIPS 140, NIST SP 800, IRS 1075, ИТAR, VPAT и CJIS.
Модель общей ответственности за безопасность в облаке
315
y
y Конкретные отрасли требуют соответствия отраслевым стандартам в при-
y
ложении. К числу отраслевых стандартов относятся PCI DSS, CDSA, MPAA,
FERPA, CMS MARS-E, NHS IG Toolkit (в Великобритании), HIPAA, FDA,
FISC (в Японии), FACT (в Великобритании), Shared Assessment и GLBA.
y Сертификация соответствия региональным стандартам относится к конкретной стране или региону. В частности, она подразумевает соответствие
стандартам 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:
Данные клиента
Ответственность клиента
Платформа, приложения, управление идентификационными данными и доступом
Операционная система, сеть и конфигурация файрволла
Шифрование данных на стороне
клиента и аутентификация
целостности данных
Шифрование на стороне сервера
(файловая система и/или данные)
Защита сетевого трафика
(шифрование/целостность/
идентификация)
Фундаментальные сервисы AWS
Вычисления
База данных
Хранение
Сети
Ответственность AWS
Глобальная
инфраструктура AWS
Регионы
Пограничные локации
Зоны доступности
Рис. 7.11. Модель общей ответственности за безопасность в AWS Cloud
y
y
y
y
y
Клиент обеспечивает безопасность в облаке, что подразумевает следующие зоны
ответственности.
y Операционная система сервера: ОС, установленная на сервере, может быть
уязвимой для атак. За установку патчей и поддержку операционной системы
отвечает клиент, так как от этого сильно зависят его приложения.
y Приложение: все приложения и их среды (разработки, тестирования, продакшен) обслуживаются клиентом. Таким образом, за реализацию политики
паролей и управление доступом отвечает клиент.
y Файрволы операционной системы/хостов: клиент должен защитить всю
свою систему от внешних атак. Облачная платформа обеспечивает безопасность в этой области, но клиенты должны применять IDS и IPS, добавляющие
дополнительный уровень безопасности.
y Сетевая конфигурация и группа безопасности: облачная платформа предоставляет инструменты для создания сетевого файрвола, но выбор трафика,
который будет остановлен или пропущен, зависит от требований приложения.
Клиенты отвечают за определение правил файрвола для защиты их систем
от внешнего или внутреннего сетевого трафика.
y Клиентские данные и шифрование: защита данных относится к обязанностям клиента, так как он лучше понимает ее необходимый уровень. Облачная
платформа предоставляет средства защиты данных за счет использования
Модель общей ответственности за безопасность в облаке
317
y
y
y
y
различных механизмов шифрования, но клиент отвечает за применение этих
средств и защиту своих данных.
Как видно из рис. 7.11, AWS и другие провайдеры публичных облачных платформ отвечают за безопасность облака, особенно физической инфраструктуры,
в которой размещаются ресурсы. Эти средства безопасности охватывают ряд
ключевых областей.
y Дата-центры: в дата-центрах AWS применяются круглосуточные меры
безопасности, включая жесткое управление доступом (с двухфакторной
аутентификацией), ведение подробных журналов входа в систему с их
регулярным анализом и видеонаблюдение. Кроме того, AWS обеспечивает
безопасную утилизацию устройств хранения данных такими методами, как
размагничивание и физическое разрушение.
y Аппаратная инфраструктура: серверы, накопители и другие устройства,
лежащие в основе сервисов AWS. AWS обеспечивает безопасность и целостность этого оборудования.
y Программная инфраструктура: операционные системы хостов, приложения сервисов и ПО виртуализации, используемое в сервисах AWS. AWS
поддерживает безопасность этого программного уровня, обеспечивая его
устойчивость перед угрозами.
y Сетевая инфраструктура: AWS защищает свою сетевую инфраструктуру,
которая включает маршрутизаторы, коммутаторы, балансировщики нагрузки,
файрволы, кабели и т. д. К этой категории мер безопасности также относится
непрерывный мониторинг внешних границ сети. AWS также обеспечивает
безопасные точки доступа и избыточную сетевую инфраструктуру для
предотвращения перебоев и повышения безопасности.
Чтобы приложение соответствовало отраслевым нормативам (например,
PCI-DSS для безопасности финансовых данных и GDPR для защиты данных
в Европе), необходимо проводить аудит жалоб уровня приложения. Публичная
облачная платформа предоставляет различные сертификаты соответствия, которые применимы к аппаратным частям под ее управлением. Клиент получает
дополнительную пользу от наследования безопасности и комплаенса, предоставляемого облачным провайдером.
Облачная платформа предлагает целый ряд инструментов и сервисов для защиты приложения в облаке, наряду со встроенной безопасностью на уровне
ИТ-инфраструктуры. Тем не менее клиент должен сам решить, как использовать эти сервисы и защищать свое приложение в облаке. Облачная платформа
предоставляет улучшенную видимость и централизованный контроль над ИТресурсами, что способствует эффективному управлению и безопасности систем.
Безопасность — приоритет для любого решения, и архитектор решений должен
позаботиться о том, чтобы приложение было безопасным и защищено от любых
атак. Постарайтесь применять лучшие практики автоматизированной безопасности там, где это возможно. Механизмы безопасности на программной основе
318
Глава 7. Факторы безопасности
могут значительно улучшить масштабируемость, экономическую эффективность
и общий уровень безопасности. Начните с создания специального эталонного
образа виртуального сервера, в который встраиваются стандарты безопасности.
В дальнейшем этот образ можно последовательно использовать для каждого нового сервера, который вы развертываете, обеспечивая однородную безопасность
инфраструктуры. Кроме того, проектируйте всю инфраструктуру по шаблону,
который определяет ее и управляет ею. Такой подход позволяет реплицировать
освоенные лучшие практики в каждой новой среде, которую вы создаете.
Безопасность — это непрерывная и планомерная работа. Каждый инцидент
безопасности следует рассматривать как возможность улучшить приложение.
Надежный механизм безопасности должен включать средства аутентификации
и авторизации. Организации и приложения должны автоматизировать реакцию
на события безопасности и защищать инфраструктуру на нескольких уровнях.
Моделирование угроз
Моделирование угроз представляет собой структурированный механизм выявления, оценки потенциальных угроз и назначения им приоритетов. Понимая
потенциальные угрозы, можно спроектировать и реализовать соответствующие
контрмеры для предотвращения, обнаружения или минимизации последствий
этих угроз. Такое моделирование часто используется в разработке ПО, но может
применяться и в других областях — например, в инфраструктуре и эксплуатации.
y
y
Нахлвем основные компоненты моделирования угроз.
y Представление системы: перед анализом угроз необходимо получить четкое
понимание системы. Для этого обычно требуется построить диаграммы или
модели архитектуры, компонентов, потоков данных и потенциальных точек
входа системы. Простой сайт интернет-магазина может включать фронтенд
для пользователей, бэкенд-сервер для обработки запросов, базу данных
с учетными данными пользователей и внешний платежный шлюз для платежей. Прежде чем запускать новую функциональность, которая позволяет
пользователям сохранять несколько адресов доставки, команда разработки
должна убедиться, что при этом не появятся новые дефекты безопасности.
Она строит диаграмму потоков данных, показывающую, как новая функцио
нальность взаимодействует с существующей системой.
y Идентификация угроз: составьте список потенциальных угроз на основании
представления системы. Это можно сделать с помощью таких методик, как
STRIDE (спуфинг, фальсификация, отказ от ответственности, раскрытие
информации, отказ в обслуживании, повышение привилегий)1 и деревья
1
Аббревиатура STRIDE от Spoofing — спуфинг, Tampering — фальсификация,
Repudiation — отказ от ответственности, Information disclosure — раскрытие информации, Denial of service — отказ в обслуживании, Elevation of privilege — повышение
привилегий. — Примеч. ред.
Моделирование угроз
319
y
y
y
y
атак. Для сайта интернет-магазина угрозы могут включать SQL-инъекции
(для доступа к базе данных), фишинг (для похищения учетных данных пользователей) или DoS-атаки (для выведения сайта из строя). Команда также
понимает, что предоставление пользователям возможности сохранять адреса
может привести к их раскрытию при утечке данных. Эта угроза включается
в общий список.
y Анализ угроз: оцените потенциальные последствия и вероятность каждой
идентифицированной угрозы. Это может помочь определить приоритеты
угроз. Так, SQLi раскрывает большой объем чувствительных пользовательских данных, а фишинговая атака затрагивает меньшее количество
пользователей, но она более вероятна. Команда разработки оценивает, что
утечка данных с раскрытием сохраненных адресов может привести к потере
доверия пользователей и потенциальным злоупотреблениям. Этой угрозе
присваивается высокая степень серьезности.
y Стратегия сокращения риска: для каждой идентифицированной угрозы
определите лучшие действия для сокращения риска. Например, добавление средств управления безопасностью, изменение системной архитектуры
или даже согласие на риск, если его потенциальные последствия приемлемы. Для предотвращения SQL-инъекции команда может использовать
параметризованные запросы, а для борьбы с фишингом — двухфакторную
аутентификацию. Для защиты адресов пользователей можно зашифровать их
в базе данных. Также можно добавить оповещения о любой подозрительной
активности, связанной с изменениями адресов.
y Документация: документируйте результаты, включая потенциальные угрозы,
их серьезность и выбранные стратегии сокращения рисков. Например, команда создает документ, в котором указано, что адреса пользователей должны
шифроваться, а также приводится используемый метод шифрования. Через
шесть месяцев появляется требование о переходе на другую базу данных.
Документация поможет команде новой базы данных понять действующие
меры безопасности.
y Анализ и обновление: моделирование угроз не является разовым мероприя
тием. С развитием систем могут появиться новые угрозы, а другие станут
менее актуальными. Регулярный анализ и обновление модели угроз гарантируют, что она остается актуальной. Например, на сайт интернет-магазина
решено добавить новую функциональность: чат-бота. Перед ее развертыванием команда обращается к своей модели угроз, чтобы узнать, приведет ли
реализация новой функциональности к появлению новых уязвимостей или
эволюции существующих угроз.
Моделирование угроз помогает командам действовать проактивно в части усилий
по обеспечению безопасности, исправляя потенциальные уязвимости до того,
как они станут проблемой.
320
Глава 7. Факторы безопасности
Итоги
В этой главе вы узнали о принципах применения лучших практик безопасности
в ходе проектирования решений. Эти принципы включают важные параметры
защиты приложения с использованием соответствующего управления доступом,
защиты данных и мониторинга.
Безопасность должна применяться на всех уровнях. Мы начали разговор
с аутентификации и авторизации пользователей, а затем вы узнали о применении безопасности на веб-уровне, а также уровнях приложения, инфраструктуры и баз данных. Каждый уровень уязвим для разных атак, и вы познакомились
с разными методами защиты приложения и вариантами выбора технологий.
В области управления пользователями вы научились применять методы FIM
и SSO для корпоративных пользователей, а также методы реализации аутентификации и авторизации пользователей. К их числу относятся такие корпоративные
сервисы управления, как Microsoft AD и AWS Directory Service. OAuth 2.0 дает
возможность обслуживать миллионы пользователей.
Вы узнали о таких типах атак на веб-уровне, как DDoS, SQLi и XSS. Вы научились защищаться от этих атак с помощью различных методов их предотвращения
и с помощью сетевых файрволов. Вы освоили методы защиты кода на уровне
приложения и обеспечения безопасности инфраструктуры. Далее мы подробно
рассмотрели различные сетевые компоненты и методы формирования доверенных границ для ограничения радиуса атаки.
Вы узнали, как организовать защиту данных путем их правильной классификации и пометкой данных как конфиденциальных, приватных или публичных.
Были рассмотрены симметричные и асимметричные алгоритмы шифрования
и различия между ними. Вы узнали о методах управления ключами для защиты
открытых/закрытых ключей шифрования. Данные могут передаваться по сети
или находиться в хранилище — мы рассмотрели защиту данных в обоих режимах. Мы исследовали безопасность API и лучшие практики обеспечения безопасности всех API, через которые осуществляются обращения к приложению.
Далее рассматривались различные модели общей ответственности и комплаенса,
применимые к облачным рабочим нагрузкам. Глава завершилась описанием
моделирования угроз.
Эта глава была посвящена применению лучших практик безопасности. Другой
критически важной характеристикой дизайна любого решения является надежность. Чтобы бизнес был успешным, необходимо создать надежное решение, которое будет постоянно доступным и справится с колебаниями рабочей нагрузки.
В следующей главе будут представлены лучшие практики, которые обеспечат
надежность приложения, а также доступные для этого технологии. Вы узнаете
о стратегиях аварийного восстановления и репликации данных, которые повышают надежность приложений.
ГЛАВА 8
ФАКТОРЫ НАДЕЖНОСТИ
АРХИТЕКТУРЫ
Надежность приложений — неотъемлемый аспект проектирования архитектуры,
жизненно важный для успеха любого бизнеса.
Надежностью (reliability) называется способность системы восстанавливаться
при сбоях. Суть ее в том, что приложение отказоустойчиво и способно восстанавливаться после любых сбоев инфраструктуры или серверов без последствий
для пользовательского опыта. Система должна быть готова к любой ситуации,
которая может привести к нарушению работоспособности.
Так как все компании сейчас работают в интернете, высокая доступность (high
availability) тоже стала обязательным критерием для онлайн-приложений.
Пользователи хотят иметь возможность открыть приложение в любой момент
и совершать покупки в интернете или банковские операции тогда, когда им это
удобно.
В этой главе рассматриваются принципы проектирования, повышающие надежность решений. При оценке надежности необходимо учитывать все компоненты
архитектуры. Вы поймете, как выбрать правильную технологию для обеспечения
надежности архитектуры на всех уровнях.
y
y
y
В этой главе рассматриваются следующие темы.
y Принципы проектирования для надежности архитектуры.
y Выбор технологии для надежности архитектуры.
y Повышение надежности на облачных платформах.
К концу главы вы будете знать различные методы аварийного восстановления
и методы репликации данных, обеспечивающие высокую доступность приложения и непрерывность бизнес-процессов.
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 — предоставляет
инфраструктуру как сервис (IaaS), облегчая доступность ресурсов по требованию. В облаке можно отслеживать обеспеченность и потребность систем. Можно
автоматизировать добавление или удаление ресурсов по мере надобности. Оно
позволяет поддерживать уровень ресурсов, который удовлетворит потребность
без чрезмерного или недостаточного резервирования.
Проверка восстановления при сбоях
Когда дело доходит до проверки инфраструктуры, в большинстве случаев организации концентрируются на проверке так называемого счастливого пути
(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
Восстановленная резервная копия
Сбой
Время
RPO
RTO
С какой частотой должны создаваться
резервные копии данных?
Как долго приложение может
оставаться недоступным?
Рис. 8.1. RTO и RPO
Например, сбой произошел в 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
Резервный
экземпляр
Асинхронная репликация данных
Основной
экземпляр
Резервный
экземпляр
Разность по времени > 0 ms
Задержка
Рис. 8.2. Синхронная и асинхронная репликация данных
Выбор технологии для архитектурной надежности
329
Рассмотрим некоторые методы репликации данных для синхронных и асинхронных решений.
Методы репликации
y
y
y
y
Методом репликации называется способ извлечения данных из исходной системы и создания копии для целей восстановления данных. Репликации могут
быть реализованы следующими способами.
y Репликация на базе массива хранения: в этом случае данные автоматически реплицируются встроенным программным обеспечением. Однако для
репликации данных исходный и приемный массив хранения должны быть
совместимыми и однородными. Массив содержит несколько дисковых накопителей на стойке.
Крупные организации применяют репликацию на базе массивов хранения для
упрощения развертывания и сокращения вычислительной мощности хостсистемы. Доступны такие продукты репликации на базе массивов хранения,
как HP Storage, EMC SAN Copy и NetApp SnapMirror.
y Репликация на базе сети: этот метод копирует данные между разными видами
разнородных массивов хранения. Для репликации данных между несовместимыми массивами хранения используется дополнительный коммутатор
или компонент. При сетевой репликации затраты на репликацию могут быть
выше, так как в процессе участвует несколько сторон. Доступны такие продукты сетевой репликации, как NetApp Replication X и EMC RecoverPoint.
y Репликация на базе хоста: в этом случае на хосте устанавливается программный агент, который может реплицировать данные в любой системе
хранения — такой, как NAS, SAN или DAS. Можно использовать хостовое
ПО от поставщика — например, Symantec, Commvault, CA или Vision Solution.
Этот способ чаще востребован малым и средним бизнесом из-за низких начальных затрат и совместимости разнородных устройств. С другой стороны,
он требует более высоких вычислительных мощностей, так как агент должен
быть установлен в операционной системе хоста.
y Репликация на базе гипервизора: этот метод работает на уровне виртуальной
машины (VM), то есть копирует всю виртуальную машину с одного хоста на
другой. Так как организации в основном используют виртуальные машины,
этот метод предоставляет очень эффективный способ аварийного восстановления для сокращения RTO. Репликация на базе гипервизора обладает высокой
масштабируемостью и потребляет меньше ресурсов, чем репликация на базе
хоста. Она может выполняться в системах, встроенных в VMWare и Microsoft
Windows. Для выполнения репликации на базе гипервизора можно выбрать
такой продукт, как Zerto, или другой от альтернативных поставщиков.
В главе 2 «Принципы проектирования архитектуры решений» мы говорили
о масштабируемости и отказоустойчивости. В главе 4 «Паттерны проектирования
архитектур решений» вы узнали о паттернах проектирования, обеспечивающих
330
Глава 8. Факторы надежности архитектуры
высокую доступность архитектуры. Теперь рассмотрим некоторые способы
восстановления системы после сбоев и обеспечения ее высокой доступности.
Планирование DR
Целью аварийного восстановления (DR) является продолжение работы системы
при сбоях. DR должно подготовить организацию к любым возможным простоям системы и предоставить возможность вывода системы из этого состояния.
Планирование DR охватывает сразу несколько измерений, включая аппаратные
и программные сбои.
При планировании аварийного восстановления всегда учитывайте как
проблемы, связанные с деятельностью организации (сбои электроснабжения,
неработоспособность сети, сбои систем обогрева и охлаждения, физические
нарушения безопасности), так и другие инциденты: пожары, наводнения,
человеческий фактор и т. д.
Организации тратят значительные усилия и средства на планирование DR
в зависимости от критичности системы и последствий ее неработоспособности.
Приложение, напрямую генерирующее доход, должно работать постоянно, так
как оно влияет на имидж компании и прибыльность бизнеса. Для таких приложений организации тратят значительные усилия на создание инфраструктуры
и обучение персонала действиям в случае аварии. DR — своего рода страховой
полис, который требует расходов по продлению даже тогда, когда вы его не
используете; с другой стороны, в критической ситуации план аварийного восстановления может стать спасительным для бизнеса.
y
y
y
y
Основные критически важные элементы — такие, как приложения — можно
разместить на условном спектре сложности. Существуют четыре сценария DR,
которые перечислены ниже в порядке убывания RTO/RPO:
y резервное копирование и восстановление;
y Pilot light («запал»);
y теплый резерв;
y горячий резерв.
Как видно из следующей диаграммы (рис. 8.3), при планировании DR с каждым
вариантом RTO и RPO убывают, а стоимость реализации растет. Необходимо
выдержать баланс между требованиями RTO/RPO и затратами на обеспечение
требований к надежности.
Сокращение RTO и RPO
Резервное копирование
и восстановление
Pilot
light
Теплый
резерв
Горячий
резерв
Сокращение затрат
Рис. 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. Факторы надежности архитектуры
Устройство
пользователя
Route 53
Облако AWS
Локальное размещение
Бакет Amazon S3
с объектом
Традиционный
сервер
AWS Snowball
Рис. 8.4. Резервное копирование данных в Amazon S3 из локальной
инфраструктуры
Можно использовать и другие сторонние решения резервного копирования.
Самые популярные варианты — NetApp, VMware, Tivoli и Commvault.
При планировании DR в облачной среде важно внедрить стратегии, использующие преимущества облачных платформ — таких, как AWS, Google Cloud
Platform (GCP) и Microsoft Azure. Это обеспечивает гибкость и устойчивость
между разными платформами. Обобщенная процедура взаимодействия между
этими облачными сервисами выглядит так.
y
y Решения резервного копирования и восстановления: используйте сервисы
y
облачного хранения для размещения резервных копий систем. Для AWS надежным сервисом хранения резервных копий может стать Amazon S3. В GCP
Google Cloud Storage предлагает надежное хранилище объектов с высокой
доступностью. Эквивалентный сервис Azure — Azure Blob Storage — предоставляет аналогичный сервис для хранения больших объемов неструктурированных данных.
y Образы машин и конфигурация: подготовьте образы машин, включающие
операционную систему, приложения и конфигурацию. AWS использует
образы AMI (Amazon Machine Image), GCP использует образы Compute
Engine, а Azure — образы Azure Virtual Machine. Эти образы можно изменить
и дополнить необходимыми патчами ПО и безопасности, чтобы они были
готовы к развертыванию в случае происшествия.
Выбор технологии для архитектурной надежности
333
y
y Документация восстановления системы: четко документируйте действия,
y
y
необходимые для восстановления системы из резервных копий на разных
облачных платформах. В документации должен быть описан процесс развертывания хранимых образов машин и восстановления баз данных и приложений из резервных копий.
y Маршрутизация трафика и процедуры отработки отказов: опишите процесс перенаправления трафика с основной площадки на резервную в облаке.
AWS предоставляет сервис Route 53 для управления DNS и маршрутизации
трафика, в GCP имеются Cloud DNS и Traffic Director, а Azure предоставляет
Azure Traffic Manager и DNS Zone. Очень важно уметь пользоваться этими
сервисами в контексте сценариев обработки отказов.
y Перечень задач: разработайте исчерпывающий перечень задач с подробным
описанием конфигураций развертывания, а также потенциальных проблем
и путей их решения. Документ должен быть облачно-нейтральным и адаптируемым к специфике 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 EC2 готовы к работе, но в настоящее время не запущены.
334
Глава 8. Факторы надежности архитектуры
Пользователь
Облако AWS
Локальное размещение
Amazon S3 Route 53
Hosted Zone
Веб-сервер
Не запущены
Веб-сервер
Сервер приложения
Сервер приложения
Зеркало/репликация данных
Сервер базы данных
Сервер базы данных
Рис. 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 EC2 с новейшей копией данных. Затем Amazon
Route 53 перенаправляется на новый веб-сервер.
Пользователь
Облако AWS
Локальное размещение
Веб-сервер
Сервер приложения
Зеркало/репликация данных
Сервер базы данных
Наращивание емкости
Amazon S3 Route 53
Hosted Zone
Сервер базы данных
Рис. 8.6. Восстановление методом Pilot light
При использовании метода Pilot light в случае сбоя необходимо выполнить
следующие действия.
1. Запустите приложение и веб-серверы, находящиеся в резервном режиме.
Также масштабируйте серверы приложения горизонтально с использованием
балансировщика нагрузки.
2. Проведите вертикальное масштабирование экземпляра базы данных, работавшего на низкой мощности.
3. Обновите запись DNS в маршрутизаторе, чтобы она указывала на новое
местоположение.
В методе Pilot light вы автоматически запускаете ресурсы, необходимые для
реплицированного основного датасета, и масштабируете систему по мере необходимости для обработки текущего трафика. Схема Pilot light относительно проста
в реализации и недорогая. С другой стороны, в этом сценарии автоматический
запуск заменяющей системы занимает больше времени, что увеличивает RTO,
336
Глава 8. Факторы надежности архитектуры
а 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
Пользователь
Облако AWS
Локальное размещение
Веб-сервер
Amazon S3 Route 53
Hosted Zone
Веб-сервер
Низкая емкость
Сервер приложения
Сервер приложения
Зеркало/репликация данных
Сервер базы данных
Сервер базы данных
Рис. 8.7. Сценарий теплого резерва в режиме «активный/активный»
при низкой емкости
Часто организация выбирает стратегию теплого резерва для критически важных рабочих нагрузок, поэтому необходимо позаботиться о том, чтобы на DRплощадке не возникало проблем; в этом вам поможет непрерывное тестирование. Лучше всего использовать A/B-тестирование, когда основная площадка
обрабатывает более значительный трафик. Небольшая доля трафика, примерно
от 1 до 5 %, направляется на DR-площадку. Это гарантирует, что она сможет
обрабатывать трафик даже при выходе из строя основной площадки. Также не
забудьте регулярно устанавливать патчи и обновления ПО на DR-площадке,
чтобы поддерживать ее синхронизацию с рабочей средой.
Как показано на рис. 8.8, во время недоступности основной среды маршрутизатор
переключается на вторичную систему, которая спроектирована для автоматического масштабирования емкости в случае отработки отказа в основной системе.
338
Глава 8. Факторы надежности архитектуры
Пользователь
Облако AWS
Локальное размещение
Веб-сервер
Запуск
Amazon S3 Route 53
Hosted Zone
Сервер приложения
Зеркало/репликация данных
Сервер базы данных
Сервер базы данных
Масштабирование до рабочей
емкости
Рис. 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площадку при необходимости. Балансировщики нагрузки и глобальные системы
управления трафиком, включая такие решения, как F5 BIG-IP и AWS Route 53,
динамически направляют трафик на основании доступности площадки и нагрузки; таким образом гарантируется, что DR-площадка сможет мгновенно
обрабатывать входящие запросы.
340
Глава 8. Факторы надежности архитектуры
Пользователь
Облако AWS
Локальное размещение
Веб-сервер
Веб-сервер
Сервер приложения
Сервер приложения
Полная емкость
Amazon S3 Route 53
Hosted Zone
Зеркало/репликация данных
Сервер базы данных
Сервер базы данных
Рис. 8.9. Сценарий горячего резерва в режиме «активный/активный»
при полной емкости в AWS
Такие инструменты IaC (Infrastructure-as-Code), как Terraform и AWS
CloudFormation, позволяют оперативно предоставлять и масштабировать необходимую инфраструктуру, чтобы DR-площадка быстро воспроизводила
функциональность рабочей среды. Кроме того, такие средства мониторинга
производительности сети, как SolarWinds и Nagios, предоставляют аналитику
работоспособности сети в реальном времени и позволяют быстро обнаруживать
проблемы, которые могут потребовать обработки отказа.
Схема горячего резерва — самая дорогостоящая из всех, так как она требует избыточности для всех компонентов. Тем не менее для бизнеса, требующего высокой
доступности и не допускающего простоев (например, финансовых учреждений,
организаций здравоохранения и платформ электронной коммерции), вложения
в реализацию горячего резерва могут быть оправданы тем, что удастся избежать
высоких потерь от потенциальных простоев.
В этом сценарии время RTO намного меньше для всех рабочих нагрузок, тогда
как RPO значительно зависит от типа репликации.
Рассмотрим некоторые лучшие DR-практики, которые обеспечивают надежную
работу системы.
Выбор технологии для архитектурной надежности
341
Применение лучших DR-практик
y
y
y
y
y
y
Планируя реализацию DR, необходимо учитывать ряд важных факторов.
y Начинайте с малого и добавляйте по мере необходимости: прежде всего
«оживляйте» критические рабочие нагрузки, оказывающие наибольшее
влияние на бизнес, и постепенно достраивайте решение, дополняя его менее
критически важными нагрузками.
y Применяйте жизненный цикл резервного копирования данных: создавайте
резервные копии всех данных, будь то файловый сервер, образ машины или
базы данных. Впрочем, хранение множества активных резервных копий может
повысить затраты, поэтому обязательно применяйте политику жизненного
цикла для архивации и удаления данных в соответствии с потребностями
бизнеса. Например, можно хранить активные резервные копии в течение
90 дней, а по истечении этого периода переносить их на более дешевые
архивные носители — например, на магнитные ленты или Amazon Glacier.
Через 1 или 2 года, согласно политике жизненного цикла, данные могут
быть удалены. Некоторые стандарты (такие, как PCI-DSS) могут требовать
хранения данных в течение 7 лет; в таком случае следует выбрать архивное
хранение для сокращения затрат.
y Проверяйте лицензии продуктов: управлять лицензиями может быть непросто, особенно в современной среде микросервисной архитектуры, где
несколько сервисов работают независимо на собственных виртуальных
машинах и базах данных. Лицензии могут быть привязаны к количеству
установок, процессоров и пользователей. Это может создать проблемы при
масштабировании. Важно отслеживать и проверять их; количество лицензий должно быть достаточным для потребностей масштабирования. Также
постарайтесь не приобретать лишние лицензии — возможно, они останутся
неиспользованными, что приведет к лишним затратам. В целом лицензиями
следует управлять так же, как инфраструктурой или ПО.
y Планируйте масштабирование: для горизонтального масштабирования
добавьте дополнительные экземпляры с установленным ПО, а для вертикального — дополнительные процессоры или память. Необходимо понимать
условия лицензионных соглашений программных продуктов и следить, чтобы
лицензий было достаточно для масштабирования системы.
y Часто тестируйте свои решения: DR-площадки создаются на случай довольно редких аварийных событий и поэтому часто остаются без внимания. Для
обеспечения высокой надежности в случае инцидента следите, чтобы решение
работало так, как задумано. Несоблюдение условий SLA может привести
к нарушению контрактных обязательств, потере денег и доверия клиентов.
y Проводите тренировочные дни: один из способов тестирования решений —
тренировочные дни. Выберите день, в который рабочая нагрузка невелика,
и соберите всю команду, ответственную за обслуживание рабочей среды. Смоделируйте происшествие: выведите из строя часть рабочей среды
342
Глава 8. Факторы надежности архитектуры
y
и посмотрите, как команда справляется с ситуацией, чтобы среда снова заработала. Такие мероприятия помогают убедиться в наличии работоспособных
резервных копий, снапшотов и образов машин для обработки аварийных
ситуаций.
y Проводите непрерывный мониторинг ресурсов: запустите систему мониторинга для автоматической обработки отказа и переключения на DR-площадку
в случае сбоя. Мониторинг помогает действовать проактивно, а отслеживание
емкости избавляет от проблемы с истощением ресурсов, которая может повлиять на надежность приложения.
Создайте DR-план и проводите регулярные проверки, чтобы обеспечить желаемую надежность приложения. В следующем разделе вы больше узнаете о повышении надежности за счет использования публичных облачных платформ.
Повышение надежности в облаке
В предыдущих разделах мы приводили примеры облачной рабочей нагрузки
для DR-площадки. Многие организации начали выбирать облако в качестве
DR-площадки в целях повышения надежности приложения. Кроме того, облачные предложения от основных провайдеров (таких, как AWS, Azure и GCP)
предлагают широкий диапазон сторонних решений, которые могут интегрироваться в планирование и выполнение DR. Эти предложения обычно включают
инструменты резервного копирования и репликации, координации, мониторинга
и безопасности.
Облачная платформа предоставляет в ваше распоряжение дата-центры в разных географических областях. Можно без малейших усилий создать надежную
площадку на другом континенте. С облачными технологиями легко создавать
инфраструктуру (например, резервные копии и образы машин) и отслеживать
ее доступность.
В облаке простой мониторинг и отслеживание помогут обеспечить высокую
доступность приложения в соответствии с условиями SLA, определяемыми бизнесом. Облако предоставляет детализированный контроль над ИТ-ресурсами,
затратами и компромиссами требований RPO/RTO.
Облачные платформы позволяют просто и эффективно протестировать DR-план.
Вы наследуете функциональность, доступную в облаке, — например, журналы
и метрики для различных облачных сервисов. Встроенные метрики становятся
мощным инструментом сбора информации о работоспособности системы.
Благодаря доступным средствам мониторинга легко оповещать команду о любых
нарушениях пороговых значений или запускать автоматизацию самовосстановления системы. Например, AWS предоставляет сервис CloudWatch, который
собирает журналы и генерирует метрики одновременно с мониторингом разных
приложений и компонентов инфраструктуры. Он может инициировать запуск
автоматизированных процессов для масштабирования приложения.
Итоги
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. Операционное совершенство
y
y
y
y
выбирать технологии, обеспечивающие удобство обслуживания на каждом
уровне приложения. Мы разберем следующие лучшие практики операционного
совершенства:
y принципы проектирования для операционного совершенства;
y выбор технологий для операционного совершенства;
y достижение операционного совершенства на публичных облачных платформах;
y повышение эффективности с помощью CloudOps.
К концу главы вы будете знать различные процессы и методы достижения
операционного совершенства. Вы узнаете о лучших практиках, применяемых
в процессе проектирования, реализации и последующей поддержки приложения.
Принципы проектирования для операционного
совершенства
Операционное совершенство — это обеспечение бесперебойной работы приложения для получения максимальной бизнес-выгоды. Это подразумевает постоянное
внедрение улучшений, повышающих эффективность системы.
Ниже мы рассмотрим стандартные принципы проектирования, которые помогут
повысить удобство обслуживания системы. Вы увидите, что все принципы проектирования операционного совершенства тесно связаны и дополняют друг друга.
Автоматизация ручных задач
Технологии стремительно развиваются, и ИТ-операции не должны отставать
от них — особенно там, где необходимое оборудование и программные продукты поставляют несколько вендоров. Корпорации строят гибридные облачные
и мультиоблачные системы, поэтому следует освоить операции как в локальных,
так и в облачных средах. Современные системы имеют обширные пользовательские базы, в них задействованы различные микросервисы и миллионы устройств,
объединенных в сеть. ИТ-операции включают множество изменяющихся компонентов, из-за чего их трудно выполнять вручную.
Организации стремятся к гибкости, и эксплуатационная команда должна
действовать быстро, чтобы обеспечивать необходимую инфраструктуру для
разработки и развертывания новых сервисов. У нее есть и еще более серьезная
задача — поддерживать бесперебойную работу сервисов и оперативно восстанавливать их в случае нештатных ситуаций. ИТ-операции требуют проактивного
подхода, а не ожидания инцидента и последующего реагирования.
Команда эксплуатации может работать очень эффективно, применяя автоматизацию. Ручные задачи должны быть автоматизированы, чтобы команда
могла сосредоточиться на стратегических инициативах и не тратить время на
Принципы проектирования для операционного совершенства
347
тактическую работу. Для разгрузки людей чрезвычайно важно автоматизировать
обнаружение любых угроз безопасности и реагирование на них. Запуск нового
сервера или запуск/остановка сервисов должны автоматизироваться с использованием подхода «инфраструктура как код» (IaC). Автоматизация позволяет
команде уделять больше времени инновациям.
Используя прогнозные методы машинного обучения, в веб-приложениях можно
обнаруживать аномалии прежде, чем они повлияют на систему. Например, можно
создать автоматическое уведомление безопасности на случай, если кто-то откроет доступ к вашему серверу через HTTP-порт 80. Почти всю инфраструктуру
можно автоматизировать и заново развернуть ее одним кликом. Автоматизация
также помогает предотвращать человеческие ошибки, которые происходят
даже в том случае, если человек постоянно выполняет одну и ту же работу. Для
ИТ-операций автоматизация стала практически обязательной.
Инкрементные и обратимые изменения
Оптимизация операций — текущий процесс, а выявление недостатков и их
исправление требуют непрерывных усилий. Эти усилия могут быть сосредоточены на надежности, доступности, производительности и экономической
эффективности. Это гарантия того, что архитектура соответствует бизнес-целям
и адаптируется к изменяющимся потребностям. Обеспечение операционного
совершенства — это постоянный процесс. Он требует регулярных изменений
во всех частях рабочей нагрузки. Например, серверные операционные системы
обычно необходимо обновлять патчами безопасности, предоставляемыми компанией-разработчиком. Также требуется обновлять версии программ, используемых приложением. Бывает, что приходится вносить изменения в систему
для соответствия новым нормативным требованиям.
Проектируйте рабочую нагрузку так, чтобы все компоненты системы можно было
регулярно обновлять, а система получала преимущество благодаря новейшим
и важным обновлениям. Автоматизируйте рабочие процессы и применяйте
в них небольшие инкрементные изменения, чтобы избежать значительных последствий. Все изменения должны быть обратимыми, чтобы при возникновении
проблем можно было восстановить рабочее состояние системы. Инкрементные
изменения упрощают тщательное тестирование и улучшают общую надежность
системы. Автоматизируйте все управление изменениями, чтобы избежать человеческих ошибок и обеспечить эффективность.
Прогнозирование сбоев и реагирование
Предотвращение сбоев крайне важно для достижения операционного совершенства. Сбои неизбежны, и очень важно выявить как их как можно раньше. В процессе проектирования архитектуры учитывайте возможность сбоев и заложите ее
в дизайн, чтобы предотвратить их возникновение. Исходите из предположения,
348
Глава 9. Операционное совершенство
что сбои будут везде и всегда, и подготовьте план резервного восстановления.
Проводите регулярные тренировки, чтобы выявить любые потенциальные источники сбоев. Попробуйте исключить или минимизировать любые ресурсы,
которые могут стать причиной сбоев во время работы системы.
Создайте на основании SLA тестовый сценарий, включающий целевое время
восстановления (RTO) и целевую точку восстановления (RPO) системы. Протестируйте сценарий и убедитесь, что понимаете все последствия его реализации.
Убедитесь, что команда готова отреагировать на любой инцидент, смоделировав
условия, близкие к реальным. Протестируйте процедуру реагирования и проверьте, что команда эффективно справляется с проблемами. Сформируйте команду,
уверенную в своих силах и знакомую с процедурой реагирования.
Анализ ошибок и выводы
При возникновении операционных сбоев в системе следует учиться на своих
ошибках и выявлять причины произошедшего. Позаботьтесь, чтобы случившиеся
события не повторялись, и приготовьте решение на случай повторения сбоя.
Один из способов, как это сделать, основан на анализе первопричин (RCA,
Root Cause Analysis). В процессе RCA вы собираете команду и задаете пять
вопросов «почему». С каждым вопросом выявляется очередной уровень проблемы, и после последнего вопроса вы добираетесь до первопричин. После
определения настоящей причины проблемы можно подготовить решение
и обновить инструкции.
Так как рабочая нагрузка будет изменяться со временем, необходимо позаботиться о соответствующем изменении операционных процедур. Обязательно
регулярно проверяйте и тестируйте все процедуры, чтобы команда была знакома
с последними обновлениями и выполняла их.
Актуализация ранбука
Зачастую команды пренебрегают документированием, и ранбук (операционная
документация) устаревает. В ранбуке приводятся рекомендации по разрешению
проблем, возникающих из-за внешних или внутренних событий. В отсутствие
актуальной документации операции начинают зависеть от человеческого фактора, что может быть рискованно из-за текучки сотрудников. Всегда определяйте
процессы так, чтобы системные операции не зависели от людей, и документируйте всё.
В ранбуке следует фиксировать все предшествующие события и меры, принятые
для решения проблемы, чтобы новые члены команды могли быстро разрешать
похожие инциденты в ходе поддержки операций.
Системный администратор должен следить за состоянием ранбука, чтобы он
содержал описание этапов запуска, остановки, установки исправлений и обновлений системы. Команда эксплуатации должна включить в него результаты
Выбор технологий для операционного совершенства
349
тестирования и проверки системы, а также описание процедуры реагирования
на событие. В ранбук также должны войти SLA, установленные в отношении
RTO/RPO, задержки, масштабируемости, производительности и т. д.
Автоматизируйте процессы аннотирования документации при внесении изменений в систему, а также после каждой сборки. Аннотации могут использоваться
для автоматизации операций, и их легко читать на программном уровне, чтобы
постоянно учитывать приоритеты бизнеса и потребности клиентов.
Выбор технологий для операционного
совершенства
Эксплуатационной команде необходимо разработать процедуры и шаги для
разрешения любых инцидентов и подтверждения эффективности своих действий. Команда должна понимать потребности бизнеса, чтобы обеспечивать
качественную поддержку, а также собирать системные и бизнес-метрики для
оценки результатов.
Операции можно разделить на три этапа — планирование, функционирование
и усовершенствование. Давайте рассмотрим технологии, которые можно использовать на каждом из них.
Планирование операционного совершенства
Первый шаг — определить приоритеты, сосредоточившись на областях со значительным влиянием на бизнес. Такими областями могут быть автоматизация,
оптимизация мониторинга, развитие навыков команды в соответствии с изменяющейся рабочей нагрузкой, а также повышение общей производительности
системы.
Существуют различные инструменты и сервисы, которые в фоновом режиме
анализируют систему, сканируя ее журналы и активность. Эти инструменты
предоставляют фундаментальный набор оценок. Оценки помогают определить
приоритеты, предоставляя ключевую информацию о системе и рекомендации
для оптимизации.
После выявления и расстановки приоритетов необходимо спроектировать
операции, в частности рабочие нагрузки и процедуры их поддержки. Проектирование рабочей нагрузки должно охватывать ее реализацию, развертывание,
процесс обновления и стратегию эксплуатации. Вся рабочая нагрузка может
рассматриваться как совокупность компонентов приложения, инфраструктуры,
безопасности, управления данными и автоматизации операций. Завершив проектирование операций, создайте чек-лист для проверки операционной готовности. Чек-листы должны быть всеобъемлющими для обеспечения готовности
к выполнению текущих операций, когда приложение будет выпущено на продакшен. К таким операциям относятся ведение журналов и мониторинг, план
350
Глава 9. Операционное совершенство
коммуникации, механизм оповещений, повышение квалификации команды,
план поддержки, механизм поддержки со стороны поставщиков и т. д.
y
y
Вот две области планирования операционного совершенства, в которых понадобятся соответствующие средства подготовки:
y управление ИТ-активами (ИТ-ресурсами);
y управление конфигурацией.
Рассмотрим эти области более подробно, чтобы понять, какие инструменты
и процессы для них доступны.
Управление ИТ-активами
y
y
y
Планирование операционного совершенства требует учета ИТ-ресурсов и контроля их использования. К таким ресурсам относятся:
y инфраструктурное оборудование (физические серверы, сетевые устройства,
системы хранения, устройства конечных пользователей и т. д.);
y программное обеспечение (лицензии программных продуктов, операционные
данные);
y юридические аспекты (контракты, соответствие нормативно-правовым
требованиям).
Другими словами, это все системы, оборудование и информация, используемые
компанией для ведения бизнеса.
Отслеживание ИТ-активов помогает организациям принимать стратегические
и тактические решения, относящиеся к поддержке и планированию операций.
Однако управлять ИТ-активами в большой организации может быть непросто.
Существуют различные инструменты управления ИТ-активами (ITAM, IT
Asset Management), которые упрощают этот процесс. Среди самых популярных
инструментов ITAM можно выделить SolarWinds, Freshservice, ServiceDesk
Plus, Asset Panda, PagerDuty и Jira Service Desk.
Управление ИТ-ресурсами не ограничивается их отслеживанием. Оно подразумевает также непрерывный мониторинг и сбор данных для оптимизации использования
ресурсов и эксплуатационных затрат. ITAM значительно повышает адаптивность
организаций, предоставляя сквозную видимость и возможность быстрой установки
обновлений и исправлений. Схема ITAM представлена на рис. 9.1.
y
y
Как показано на диаграмме, процесс ITAM включает следующие этапы.
y Планирование: жизненный цикл актива начинается с планирования — стратегического анализа для определения необходимости в ИТ-активах и методах
их приобретения. Планирование включает оценку экономической выгоды
и расчет совокупной стоимости владения (TCO).
y Приобретение: организация приобретает активы на основании результатов
планирования. Она также может выбрать самостоятельную разработку
Выбор технологий для операционного совершенства
351
y
y
y
некоторых компонентов — например, собственного ПО для ведения журналов и мониторинга.
y Интеграция: актив внедряется в ИТ-экосистему. Этот этап включает настройку работы и поддержку актива, в том числе определение прав доступа
пользователей — например, установку агента, который собирает данные
журналов со всех серверов в централизованном дашборде, и ограничение
отслеживания метрик в дашборде только командой эксплуатации.
y Обслуживание: команда эксплуатации отслеживает ресурсы и принимает меры для их обновления или миграции на основании их жизненного
цикла — например, установку патчей безопасности, предоставляемых
разработчиком ПО. Для этого необходимо отслеживать срок жизни лицензируемого ПО (например, запланировать миграцию с Windows Server
2008 на Windows 2022, так как старая операционная система скоро перестанет поддерживаться).
y Списание: на этапе списания команда эксплуатации избавляется от ресурсов
с истекшим сроком жизни. Например, если срок жизни сервера базы данных
подходит к концу, команда принимает меры по его замене и миграции необходимых пользователей и поддержки на новый сервер.
Планирование
Управление
ИТ-активами
Списание
Обслуживание
Рис. 9.1. Процесс ITAM
Приобретение
Интеграция
352
Глава 9. Операционное совершенство
ITAM помогает организациям соблюдать требования к соответствию стандарту
ISO 19770. Процедура предусматривает этапы приобретения ПО, развертывания, обновления и поддержки. ITAM обеспечивает повышенную безопасность
данных и соответствие нормативам в этой области. Кроме того, ITAM улучшает
коммуникации между подразделениями — например, командами эксплуатации,
финансов, маркетинга и клиентской поддержки.
Управление конфигурацией — еще один важный аспект планирования операционного совершенства, который помогает поддерживать актуальные данные
об ИТ-активах, включая информацию о владельце и текущем состоянии. Рассмотрим эту тему более подробно.
Управление конфигурацией
Управление конфигурацией обеспечивает обслуживание элементов конфигурации (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. Операционное совершенство
Рис. 9.3. Дашборд AWS Trusted Advisor
Как показано на снимке, AWS Trusted Advisor находит 12 проблем с безопасностью, которые можно дополнительно исследовать для получения более подробной информации.
y
y
y
y
y
y
Управление конфигурацией играет ключевую роль в непрерывном мониторинге
и документировании конфигураций ИТ-ресурсов. Оно позволяет автоматизировать оценку конфигураций по заранее определенным стандартам. Перечислим
некоторые преимущества управления конфигурацией.
y Непрерывный мониторинг делает возможным текущее наблюдение и документирование изменений в конфигурациях ИТ-ресурсов.
y Управление изменениями помогает отслеживать взаимосвязи между
ресурсами и анализировать зависимости перед реализациями любых изменений.
y Непрерывная оценка упрощает регулярный аудит и проверки того, что
ИТ-ресурсы соответствуют политикам и рекомендациям организации.
y Мониторинг соответствия в масштабах организации дает комплексное
представление о статусе соответствия нормативам в масштабах организации,
выявляет все несоответствия и позволяет проводить углубленный анализ на
региональном уровне.
y Управление сторонними ресурсами позволяет документировать конфигурации для сторонних ресурсов: репозиториев GitHub, ресурсов Microsoft
Active Directory и серверов (как локальных, так и находящихся в облаке).
y Операционная диагностика сохраняет подробную историю изменений конфигурации, что упрощает разрешение эксплуатационных проблем.
Выбор технологий для операционного совершенства
355
Управление конфигурацией дает возможность проведения анализа безопасности, непрерывного наблюдения за конфигурациями ресурсов и оценки этих
конфигураций на предмет потенциальных уязвимостей безопасности. Оно
играет важную роль обеспечении соблюдения внутренних политик и нормативных стандартов в конфигурациях ИТ-ресурсов (как внутри организации,
так и внешних) и непрерывном анализе изменений конфигурации ресурсов
относительно желаемых стандартов.
В этом разделе вы узнали об управлении ресурсами и конфигурациями. Они
являются частью фреймворка ITIL (Information Technology Infrastructure
Library), реализующего набор процессов ITSM (Information Technology Service
Management), актуальный для операционной эффективности. ITSM помогает
организациям в ежедневном ведении ИТ-операций. Узнать больше об ITIL
можно на сайте его руководящего органа, AXELOS (https://www.axelos.com/bestpractice-solutions/itil). AXELOS предлагает сертификацию ITIL для повышения
квалификации в процессе управления ИТ-сервисами.
После знакомства с планированием перейдем к рассмотрению функционирования ИТ-операций.
Достижение операционного совершенства
Операционное совершенство достигается путем проактивного мониторинга
и скоростью реагирования и восстановления в случае нештатных ситуаций. Понимая состояние рабочей нагрузки, можно определить, как события и реакции
на них влияют на ее работоспособность. Используйте инструменты, которые
помогают оценить состояние системы при помощи метрик и дашбордов. Отправляйте данные журналов в централизованное хранилище и определяйте метрики для определения эталонных значений. Эти инструменты также позволяют
автоматизировать реакцию на события и инициировать их выполнение в ответ
на конкретные оповещения.
Проектируйте компоненты рабочей нагрузки так, чтобы они были заменяемыми.
Это позволит не тратить время на решение проблем, а сокращать срок
восстановления заменой неработоспособных компонентов надежными,
известными версиями. Затем можно проанализировать неработоспособные
ресурсы, не затрагивая продакшен-среду.
y
y
Для достижения операционного совершенства вам понадобятся специальные
инструменты в следующих областях:
y мониторинг работоспособности системы;
y обработка оповещений (алертов) и реагирование на инциденты.
Рассмотрим эти области и доступные для них инструменты и процессы.
356
Глава 9. Операционное совершенство
Мониторинг работоспособности системы
Отслеживание работоспособности системы абсолютно необходимо для понимания поведения рабочей нагрузки. Команда эксплуатации использует мониторинг
работоспособности системы для регистрации любых аномалий в компонентах
системы и выполнения соответствующих действий.
y
y
y
y
y
Традиционно мониторинг ограничивается уровнем инфраструктуры, отслеживанием загруженности памяти и процессоров на серверах. Однако его необходимо проводить на каждом уровне архитектуры. Важнейшие части системы,
требующие мониторинга:
y инфраструктура;
y приложения;
y платформа;
y журналы;
y безопасность.
Мониторинг этих компонентов рассматривается в следующих подразделах.
Мониторинг инфраструктуры
Мониторинг инфраструктуры чрезвычайно важен, и это самая востребованная
разновидность мониторинга. Инфраструктура включает компоненты, необходимые для хостинга приложений. К ней относятся такие базовые сервисы, как
хранение данных, серверы, сетевой трафик, балансировщики нагрузки и т. д.
y
y
y
y
y
Мониторинг инфраструктуры может включать следующие метрики.
y Загруженность процессора: процент использования ЦП сервером за определенный период.
y Загруженность памяти: процент оперативной памяти (ОЗУ, или RAM),
используемой сервером за определенный период.
y Использование сети: количество входящих и исходящих пакетов за определенный период.
y Использование диска: пропускная способность диска для чтения/записи
и количество операций ввода/вывода в секунду (IOPS).
y Балансировщик нагрузки: счетчики количества запросов за определенный
период.
Существуют и другие метрики; организации должны настраивать их в соответствии с особенностями приложения. На рис. 9.4 показан пример дашборда для
мониторинга сетевого трафика.
Выбор технологий для операционного совершенства
357
Из снимка экрана видно, что в один день наблюдался выброс на панели среднего
входящего сетевого трафика (Network In Average), с цветовым кодированием
разных серверов. Команда эксплуатации может тщательно изучить этот и другие
графики и ресурсы, чтобы получить более детализированное понимание общей
работоспособности инфраструктуры.
Рис. 9.4. Дашборд мониторинга сетевого трафика
Мониторинг приложения
Иногда инфраструктура полностью работоспособна, но в приложениях возникает
проблема, обусловленная ошибкой в коде или стороннем ПО. Возможно, вы
установили патч безопасности для операционной системы, предоставленный вендором, и это нарушило работу системы. Мониторинг поможет решить проблему.
Мониторинг приложения может включать следующие метрики.
y
y
y
y Вызовы эндпоинта: количество запросов за заданный период.
y Время отклика: среднее время отклика на запрос.
y Троттлинг: количество валидных запросов, отклоненных из-за того, что
y
система не может справиться с дополнительной нагрузкой.
y Ошибки: сбои при обработке запросов.
На рис. 9.5 представлен дашборд с данными мониторинга эндпоинта некоторого
приложения.
358
Глава 9. Операционное совершенство
Рис. 9.5. Дашборд мониторинга приложения
Можно использовать и другие метрики в зависимости от приложения
и технологии — например, затраты памяти на сборку мусора для приложений Java, примеры запросов HTTP POST и GET для сервиса RESTful, счетчик
клиентских ошибок 4XX, счетчик серверных ошибок 5XX для веб-приложения
и любые другие, которые могут указывать на плохую работоспособность приложения.
Мониторинг платформы
y
y
y
y
y
y
y
y
Приложение может использовать разные сторонние платформы и инструменты,
для которых необходимо проводить мониторинг. К числу таких инструментов
относятся:
y кэширование памяти: Redis и Memcached;
y реляционная база данных: Oracle Database, Microsoft SQL Server, Amazon
Relational Database Service (RDS), PostgreSQL;
y база данных NoSQL: Amazon DynamoDB, Apache Cassandra, MongoDB;
y платформа больших данных: Apache Hadoop, Apache Spark, Apache Hive,
Apache Impala, Amazon Elastic MapReduce (EMR);
y контейнеры: Docker, Kubernetes, OpenShift;
y средства бизнес-анализа: Tableau, MicroStrategy, Kibana, Amazon QuickSight;
y система обмена сообщениями: MQSeries, Java Message Service (JMS),
RabbitMQ, Simple Queue Service (SQS);
y поиск: OpenSearch, приложение на базе Solr.
Каждый из инструментов, упомянутых выше, имеет собственный набор метрик,
которые необходимо отслеживать, чтобы гарантировать работоспособность
всего приложения. На рис. 9.6 представлен дашборд мониторинга платформы
для реляционной базы данных.
Выбор технологий для операционного совершенства
359
Рис. 9.6. Дашборд мониторинга платформы для реляционной базы данных
Из этого дашборда видно, что база данных выполняет большой объем операций записи, то есть приложение постоянно записывает данные. С другой
стороны, операции чтения относительно стабильны, если не считать нескольких пиков.
Мониторинг журналов
Традиционно мониторинг журналов проводился вручную. Организации только
реагировали на происходящее и переходили к анализу журналов при обнаружении ошибок. Однако с усилением конкуренции и повышением пользовательских
ожиданий возникла необходимость быстро принимать меры еще до того, как
пользователь заметил проблему. Чтобы действовать проактивно, необходимо
иметь возможность пересылать журналы в централизованное хранилище и выполнять запросы для мониторинга и выявления проблем. Например, если страница какого-то товара выдает ошибку, необходимо немедленно ее распознать
и исправить до того, как пользователи начнут жаловаться; в противном случае
вы рискуете потерять деньги.
В случае любых сетевых атак необходимо проанализировать сетевой журнал
и заблокировать подозрительные IP-адреса. Эти IP-адреса могут отправлять
аномальное количество пакетов данных, чтобы нарушить работу приложения.
Такие системы мониторинга, как AWS CloudWatch, Logstash, Splunk, Google
Stackdriver и др., предоставляют агент, который необходимо установить на сервере приложения. Агент пересылает журналы в централизованное хранилище.
Можно напрямую обращаться с запросами к централизованному хранилищу
журналов и включать оповещения о любых аномалиях.
На рис. 9.7 представлен пример сетевого журнала, находящегося в централизованном хранилище.
360
Глава 9. Операционное совершенство
Рис. 9.7. Неформатированные данные журнала, переданные
в централизованное хранилище данных
Например, можно выполнить запрос к журналам и узнать top-10 IP-адресов
с наибольшим количеством отклоненных запросов (рис. 9.8).
Как видно из скриншота редактора запросов, можно построить график и включить оповещение при превышении определенного порога отклоненных запросов — например, 5000.
Мониторинг безопасности
Безопасность — важнейшая характеристика любого приложения. При проектировании решений необходимо предусмотреть мониторинг безопасности. Как вы
узнали из главы 7 «Факторы безопасности», безопасность должна реализовываться на всех уровнях. Рекомендуется реализовать мониторинг безопасности
так, чтобы активно реагировать на любые нежелательные события.
y
y
y
y
y
Ниже перечислены уровни, на которых должен осуществляться мониторинг
безопасности.
y Сетевая безопасность: мониторинг любых несанкционированных открытий
портов, подозрительных IP-адресов и активности.
y Пользовательский доступ: мониторинг любых несанкционированных пользовательских обращений и подозрительной пользовательской активности.
y Безопасность приложений: мониторинг для выявления вредоносного ПО
и вирусных атак.
y Веб-безопасность: мониторинг для выявления DDoS-атак, внедрения SQLинъекций и межсайтовых скриптовых атак (XSS).
Безопасность
сервера: мониторинг любых пропусков в установке патчей
y
безопасности.
Выбор технологий для операционного совершенства
361
y
y Комплаенс: выявление любые нарушений, например проверка соответствия
y
PCI (Payment Card Industry) для платежных приложений или соответствия
HIPAA (Health Insurance Portability and Accountability Act) для приложений
из области здравоохранения.
y Безопасность данных: мониторинг несанкционированных обращений
к данным, маскирования данных и шифрования данных при хранении
и передаче.
Рис. 9.8. Информация, полученная в результате выполнения запроса
к сетевому журналу
Пример мониторинга безопасности с использованием Amazon GuardDuty для
облачной платформы AWS представлен на рис. 9.9.
362
Глава 9. Операционное совершенство
Рис. 9.9. Мониторинг безопасности с использованием Amazon GuardDuty
Другие инструменты, которые могут использоваться для мониторинга безопасности, — Imperva, McAfee, Qualys, Palo Alto Networks, Sophos и Symantec.
При установке средств мониторинга приложения очень важно контролировать
саму систему мониторинга. Обязательно организуйте мониторинг хоста системы
мониторинга. Например, если система мониторинга размещена в Amazon EC2
(Elastic Compute Cloud), то для контроля работоспособности EC2 можно использовать AWS CloudWatch.
Оповещения и реагирование на инциденты
Мониторинг — одна из составляющих операционного совершенства. Другой
составляющей является система оповещений (алертов) и реагирования на них.
Можно определять системные пороговые значения и условия срабатывания для
оповещений. Например, если загруженность сервера достигает 70 % в течение
5 минут, система мониторинга регистрирует факт высокой загруженности
и отправляет оповещение команде эксплуатации, чтобы та приняла меры для
снижения загруженности процессора до того, как система выйдет из строя. В качестве реагирования на этот инцидент команда может добавить сервер вручную.
Если включена автоматизация, автомасштабирование выдает оповещение, что
необходимо добавить дополнительные серверы. При этом команде эксплуатации отправляется уведомление, с которым она может разобраться позже.
Реагирование на инциденты необходимо для того, чтобы обработать полученные
оповещения и решить проблемы. Действия для решения проблем с перебоями
в работе системы или ошибками могут выполняться автоматически или управляться командой эксплуатации. Это гарантия того, что любые нарушения будут
быстро и эффективно устранены, а их последствия для деятельности организации
минимизированы. Таким образом обеспечиваются надежность и доступность
системы для пользователей и стейкхолдеров.
Выбор технологий для операционного совершенства
363
y
y
y
y
y
Полезно определить категории оповещений, чтобы команда эксплуатации была
готова реагировать в соответствии с серьезностью оповещения. Ниже показан
пример классификации оповещений по приоритетам.
y Уровень 1: критически важная проблема. Уровень 1 означает значительные
последствия для клиентов, требующие немедленного реагирования. Оповещение уровня 1 может указывать на то, что все приложение вышло из
строя. Стандартное время реагирования на такие оповещения — 15 минут,
а решением проблемы необходимо заниматься в режиме 24/7.
y Уровень 2: высокоприоритетное оповещение, которое должно обрабатываться
в рабочее время. Например, приложение работает, но система оценок и отзывов для конкретной категории товаров — нет. Стандартное время реагирования на такие оповещения — 24 часа, а решением проблемы необходимо
заниматься в рабочее время.
y Уровень 3: оповещение со средним приоритетом, которое может обрабатываться в рабочее время в течение нескольких дней, — например, оповещение
о том, что диск сервера будет заполнен через 2 дня. Стандартное время реагирования на такие оповещения — 72 часа, решением проблемы необходимо
заниматься в рабочее время.
y Уровень 4: низкоприоритетное оповещение, которое может обрабатываться
в рабочее время в течение недели, — например, оповещение о том, что срок
действия сертификата SSL истечет через 2 недели. Стандартное время реагирования на такие оповещения — неделя, решением проблемы необходимо
заниматься в рабочее время.
y Уровень 5: относится к категории уведомлений, не требует эскалации и может быть простой информацией — например, уведомлением о завершении
развертывания. Ответной реакции не требует, так как существует только для
информационных целей.
Каждая организация может определять разные уровни серьезности оповещений
в зависимости от своих потребностей. Одним организациям достаточно четырех
уровней безопасности, другие могут определить шесть. Кроме того, различаться
может и время реагирования. Некоторые организации могут требовать реагирования на оповещения уровня 2 в течение 6 часов в режиме 24/7, а не только
в рабочее время.
Настраивая оповещения, следите, чтобы их название и краткое описание были
содержательными и лаконичными, поскольку они часто отправляются на мобильное устройство (в формате SMS) или пейджер (как текстовое сообщение)
и получатель должен немедленно отреагировать на них. Не забудьте включить
данные метрик в тело сообщения. Например, лучше указать конкретную информацию вида «На сервере production-web-1 диск заполнен на 90 %» вместо простого
сообщения «Диск заполнен». На рис. 9.10 приведен скриншот из CloudWatch
с примером дашборда.
364
Глава 9. Операционное совершенство
Рис. 9.10. Дашборд оповещений
На скриншоте показано оповещение о том, что таблица базы данных NoSQL
Amazon DynamoDB с именем testretail демонстрирует низкую утилизацию
выделенных единиц записи, что создает лишние затраты.
Четыре нижних и два верхних оповещения имеют статус OK, так как данные,
полученные в ходе мониторинга, лежат в пределах пороговых значений.
Иногда в оповещении может быть указано «недостаточно данных»; это
означает, что для определения состояния отслеживаемых ресурсов требуется
больше точек данных.
В случае критически важных оповещений важно протестировать реагирование
на инцидент, чтобы удостовериться, что поддержка готова отреагировать на него
в соответствии с условиями SLA. Проверьте правильность настройки порогов,
чтобы у вас было достаточно времени для решения проблемы, и не отправляйте
слишком много оповещений. Убедитесь, что сразу же после решения проблемы
оповещение возвращается в исходное состояние и снова готово к сохранению
данных событий.
Инцидентом считается любое незапланированное нарушение нормальной работы, которое отрицательно влияет на систему и клиента. Первой реакцией на
инцидент должно стать восстановление системы и взаимодействий с клиентом.
Устранением первопричины можно заняться позже, когда система будет восстановлена и начнет функционировать. Автоматизированное оповещение помогает
активно обнаружить инцидент и минимизировать последствия для пользователя. Например, при выходе из строя всей системы можно переключиться на
площадку аварийного восстановления. Основная система будет исправлена
и восстановлена позже.
Выбор технологий для операционного совершенства
365
Компания Netflix использует Simian Army («Армию обезьян») ( https://
netflixtechblog.com/the-netflix-simian-army-16e57fbab116) — набор инструментов для тестирования устойчивости систем, включающий Chaos Monkey
(«обезьяну хаоса»). Chaos Monkey случайным образом завершает работу
продакшен-серверов, чтобы проверить, сможет ли система отреагировать на
аварийные ситуации без последствий для конечных пользователей. У Netflix
также имеются другие инструменты для тестирования различных измерений
системной архитектуры: Security Monkey (проверка уязвимостей безопасности), Latency Monkey (задержки в сети) и даже Chaos Gorilla (моделирует
отказ целой зоны доступности).
Мониторинг, оповещения и реагирование на инциденты — важнейшие составляющие операционного совершенства. В любой системе мониторинга обычно
имеется встроенная функциональность оповещений. Полностью автоматизированная система оповещений и мониторинга улучшает способность команды
эксплуатации поддерживать работоспособность системы и применять свой опыт,
помогая быстро принимать меры и улучшать взаимодействие с пользователями.
В процессе мониторинга среды приложения очень важно проводить непрерывные улучшения и постоянно стремиться к совершенству. Рассмотрим тему
непрерывного улучшения более подробно.
Развитие операционного совершенства
Непрерывное улучшение необходимо для успеха любого процесса, продукта
или приложения. Операционное совершенство также нуждается в непрерывном
улучшении, чтобы со временем достичь зрелости.
y
y
y
При анализе первопричин (RCA, root cause analysis) рекомендуется вносить
небольшие инкрементные изменения. Умение пользоваться данными о прошлых сбоях поможет подготовиться к разным событиям, которые могут быть
как запланированными (например, развертывания), так и незапланированными
(например, резкий рост загруженности ресурсов). Регистрируйте всю информацию и обновляйте рекомендации в ранбуке. Для развития операционного совершенства понадобятся соответствующие инструменты в следующих областях:
y аналитика ИТ-операций (ITOA, IT operations analytics);
y анализ первопричин (RCA);
y аудит и отчеты.
Аналитика ИТ-операций
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 и т. д. —
предоставляют широкий выбор встроенных возможностей и рекомендаций для
достижения операционного совершенства в облаке — например, автоматизацию.
y
y
y
Следующие сервисы AWS помогут обеспечить операционное совершенство.
y Сервисы AWS для этапа планирования:
AWS Trusted Advisor: проверяет рабочую нагрузку на основе заданных
лучших практик и предоставляет рекомендации по их реализации.
AWS CloudFormation: с AWS CloudFormation вся рабочая нагрузка
может рассматриваться как код, включая приложения, инфраструктуру,
политику, управление и операции.
AWS Systems Manager: предоставляет возможность управления облачными серверами для массовой установки исправлений, обновлений
и общего обслуживания.
y Сервисы AWS для этапа функционирования:
Amazon CloudWatch: предоставляет сотни встроенных метрик для мониторинга операций рабочей нагрузки и выдачи оповещений по достижении
определенных порогов. Он предоставляет систему централизованного
управления журналами и инициирует автоматизированное реагирование
на инциденты.
AWS Lambda: этот сервис AWS может использоваться для автоматизации
реагирования на операционные события.
y Сервисы AWS для этапа развития (улучшения):
Amazon OpenSearch: может использоваться для анализа данных журналов с целью получения и применения аналитики для обучения на
основе опыта.
AWS CodeCommit: полученная на основе опыта информация может распространяться в библиотеках, скриптах и документации, сохраняемых
в центральном репозитории как код.
AWS обеспечивает функциональность для предоставления приложений и инфраструктуры в виде кода. Эти средства помогают автоматизировать операции
370
Глава 9. Операционное совершенство
и реагирование на инциденты. С AWS неработоспособные компоненты можно
легко заменить работающими версиями и анализировать их без влияния на
продакшен-среду.
В AWS можно собирать и объединять журналы системных операций, активностей рабочей нагрузки и инфраструктуры для создания полной истории
операций — при помощи таких сервисов, как AWS CloudTrail. Затем можно
воспользоваться инструментами AWS для запроса и анализа операционных
журналов во времени. Этот анализ поможет выявить области потенциальных
усовершенствований и повысить эффективность и безопасность системы. В облаке обнаружение ресурсов выполняется просто, так как все они находятся под
API- и веб-интерфейсами в одной иерархии. Вы также можете отслеживать
локальную рабочую нагрузку из облака. Для целей аудита безопасности в облаке AWS Amazon GuardDuty и Amazon Detective предоставляют отличную
аналитику и подробные данные по многим учетным записям.
Операционное совершенство должно поддерживаться непрерывно. Каждый
сбой должен тщательно анализироваться для повышения производительности
и надежности приложения. Этот процесс требует понимания специфических
потребностей и характеристик нагрузки приложения и соответствующей адаптации стратегий эксплуатации. Более того, если документировать повседневную
активность в виде ранбука, следовать схемам решения проблем, пользоваться
автоматизацией и повышать осведомленность, эксплуатационная команда будет
готова к любым сбоям.
Повышение эффективности с CloudOps
Термином CloudOps обозначаются процессы, инструменты и лучшие практики
эффективной эксплуатации и управления облачными средами. К преимуществам
CloudOps относятся повышение эффективности, сокращение затрат, обеспечение
безопасности и комплаенса, ускорение восстановления после сбоев и возможность быстрого масштабирования.
y
y
Перечислим ключевые принципы CloudOps, применимые независимо от облачных провайдеров.
y Настройка управления: реализуйте безопасную, хорошо спроектированную среду. Используйте такие инструменты, как AWS Organizations, Azure
Management Groups или Google Cloud Resource Manager для организации
и управления учетными записями. Обеспечьте соблюдение политик при
помощи таких инструментов, как AWS Control Tower, Azure Blueprints или
Google Cloud Policy Intelligence.
y Комплаенс: организуйте непрерывный мониторинг конфигурации при помощи таких инструментов, как AWS Config, Azure Policy или Google Cloud
Security Command Center. Автоматизируйте проверки соответствия и исправления для целей соответствия отраслевым стандартам.
Повышение эффективности с CloudOps
371
y
y Выделение ресурсов и оркестрация: ускорьте настройку среды при помощи
y
y
y
средств «инфраструктуры как кода» с инструментами AWS CloudFormation,
шаблонами Azure Resource Manager или Google Cloud Deployment Manager.
Применяйте такие инструменты, как AWS Service Catalog, Azure Service
Catalog или Google Cloud Service Catalog, для управления стандартизированными портфелями ИТ-сервисов.
y Мониторинг и наблюдение: обеспечьте наблюдаемость при помощи таких
инструментов, как AWS CloudWatch, Azure Monitor или Google Cloud
Operations Suite. Быстро выявляйте и диагностируйте проблемы для поддержания производительности и надежности системы.
y Централизация операций: управляйте инфраструктурой в масштабе при помощи таких инструментов, как AWS Systems Manager, Azure Automation или
Google Cloud Operations, для автоматизации и централизации управления,
улучшая операционную эффективность.
y Управление затратами: управляйте затратами и оптимизируйте их при помощи таких инструментов, как AWS Cost Explorer, Azure Cost Management
или Google Cloud Cost Management. Планируйте бюджеты, проводите мониторинг затрат и выявляйте аномалии, чтобы держать затраты под контролем.
Придерживаясь практик CloudOps, вы сможете поддерживать целостную и эффективную операционную платформу независимо от облачной среды.
Автоматизация является основой CloudOps. Она позволяет организациям управлять сложными облачными средами с большей эффективностью и меньшим
количеством ошибок. Например, изменения инфраструктуры, которые при ручной реализации создают высокий риск ошибок, автоматизируются при помощи
AWS CloudFormation или похожих средств, обеспечивая последовательность
и высокую скорость выполнения операции. Когда при мониторинге с помощью
таких инструментов, как AWS CloudWatch, обнаруживаются проблемы с производительностью, можно запустить автоматизированные действия для решения
этих проблем без ручного вмешательства.
Переход на принципы CloudOps начинается с основ управления и комплаенса.
Например, агентство диджитал-маркетинга может начать с защиты своих облачных сред в соответствии с лучшими практиками, а затем уже переходить на
полную автоматизацию пайплайнов развертывания. С ростом агентства совместная работа команд становится решающим условием для распространения лучших
практик и инструментов. Начиная с организации управления и комплаенса
и постепенно внедряя автоматизацию, команды могут эффективно управлять
затратами и масштабировать свои операции.
C CloudOps весь жизненный цикл создания, развертывания, мониторинга и эксплуатации в облачных средах значительно упрощается, открывая возможности
для Agile-разработки и операционного совершенства.
372
Глава 9. Операционное совершенство
В качестве примера в книге мы рассматриваем AWS, но те же концепции
применимы для любых публичных облачных платформ — в частности, GCP
и Azure.
Узнать больше о CloudOps можно в другой нашей книге, «AWS for Solutions
Architects».
Итоги
Операционного совершенства можно достичь путем непрерывных улучшений
с учетом текущих потребностей и прошлого опыта. Используйте для разработки и управления приложениями методы, которые повышают эффективность
и обеспечивают высокую отзывчивость развернутых сред. Реализация лучших
практик в отношении рабочей нагрузки обеспечит достижение операционного
совершенства.
В этой главе вы узнали о принципах проектирования, которые помогают добиться операционного совершенства. Среди них — автоматизация операций,
непрерывное улучшение, инкрементный подход, прогнозирование сбоев и готовность к реагированию на сбои.
Вы узнали о разных этапах операционного совершенства и соответствующих
им технологиях. Для этапа планирования было рассмотрено применение ITAM
в целях отслеживания ИТ-активов и выявления зависимостей между ними с использованием управления конфигурацией.
Вы узнали об организации оповещений и мониторинга на этапе функционирования, а также познакомились с разными видами мониторинга, включая мониторинг инфраструктуры, приложений, журналов, безопасности и платформы. Вы
узнали о важности оповещений и о том, как определять серьезность оповещений
и реагировать на них.
Для этапа развития операционного совершенства мы рассмотрели применение
аналитики на основе построения пайплайна big data, методы применения анализа
первопричин (RCA) с использованием пяти вопросов «почему», а также важность
аудита для защиты системы от вредоносной активности и незамеченных угроз.
Вы узнали об операционном совершенстве в облаке и встроенных инструментах, которые можно использовать для его обеспечения на облачной платформе
AWS. Глава завершилась описанием подхода CloudOps и его потенциала для
упрощения облачных операций.
К этому моменту вы узнали о лучших практиках в областях производительности,
безопасности, надежности и операционного совершенства. В следующей главе
будут представлены лучшие практики оптимизации затрат. Вы также изучите
инструменты и приемы оптимизации общих системных затрат, а также возможности применения разных инструментов на облачной платформе для управления
затратами на ИТ.
ГЛАВА 10
ОПТИМИЗАЦИЯ ЗАТРАТ
В предыдущей главе вы узнали об операционном совершенстве и применении
автоматизации. Автоматизация снижает риск человеческих ошибок, повышает
эффективность и в конечном счете снижает затраты. Оптимизация затрат на
архитектуру — важнейшее условие поддержания эффективной и жизнеспособной ИТ-среды. Для его выполнения требуется понимать и управлять ресурсами,
которые потребляют приложения, а также контролировать, что вы платите только за то, что действительно вам нужно. В этой главе мы исследуем различные
стратегии оптимизации затрат, включая правильный подбор ресурсов, модели
ценообразования, а также инструменты для бюджетирования и управления
затратами.
Одна из главных целей любого бизнеса — повышение прибыли при обслуживании клиентов. Затраты — одна из важнейших тем, обсуждаемых при запуске
проекта. Обновления приложений и добавление новой функциональности
в продукты зависят от доступного финансирования. Затраты на продукт должны
учитываться всеми участниками проекта, и их необходимо анализировать на
каждом этапе жизненного цикла продукта (от планирования до эксплуатации).
Эта глава поможет понять лучшие практики оптимизации затрат на ИТ-решения
и эксплуатацию.
Оптимизация затрат — непрерывный процесс, которым необходимо тщательно
управлять без ущерба для пользовательского опыта. Оптимизация означает не
снижение затрат, а сокращение бизнес-рисков за счет максимизации окупаемости
(ROI). Прежде чем планировать любые стратегии и действия по оптимизации
затрат, необходимо понять потребности клиентов. Часто клиенты, стремящиеся
к качеству, готовы заплатить более высокую цену.
y
y
В этой главе обсуждаются принципы проектирования для оптимизации затрат.
Вопрос затрат должен учитываться для каждого этапа и компонента архитектуры. Вы узнаете, как правильно выбирать технологии для оптимизации затрат на
каждом уровне. Мы рассмотрим лучшие практики оптимизации затрат:
y принципы проектирования для оптимизации затрат;
y приемы оптимизации затрат;
374
Глава 10. Оптимизация затрат
y
y
y управление оптимизацией затрат на публичной облачной платформе;
y «зеленые» ИТ и их влияние на затраты.
К концу главы вы освоите различные методы оптимизации затрат без риска для
адаптивности бизнеса и его результатов, а также научитесь отслеживать затраты
и контролировать их. Впрочем, обо всем по порядку: начнем с принципов проектирования для оптимизации затрат, то есть принципов, которые закладывают
фундамент для построения архитектуры с учетом затрат.
Принципы проектирования для оптимизации
затрат
Оптимизация затрат подразумевает повышение бизнес-ценности и минимизацию риска при сокращении издержек. Желательно планировать затраты на
приложение с оценкой бюджета и прогнозированием расходов. Чтобы добиться
экономии, необходимо ввести план оптимизации затрат и тщательно отслеживать издержки.
Существует ряд принципов, которые способствуют оптимизации затрат; самые
распространенные из них рассматриваются в следующих разделах. Как вы убедитесь, все принципы проектирования для оптимизации затрат тесно связаны
и взаимно дополняют друг друга. Рассмотрим их подробнее.
Вычисление суммарной стоимости владения
Часто организации упускают из вида совокупную стоимость владения (TCO,
Total Cost of Ownership) и принимают решения на основании исходных затрат
на приобретение программ и сервисов, так называемых капитальных затрат
(CapEx, Capital Expenditure). Хотя определить исходные затраты важно, в долгосрочной перспективе главное значение имеет TCO, которая включает как CapEx,
так и операционные затраты (OpEx).
CapEx — это цена, которую организации платят единовременно для приобретения программного и аппаратного обеспечения, а в OpEx входят затраты
на эксплуатацию, обслуживание и списание ПО и оборудования, а также на
обучение сотрудников. Чтобы принимать стратегические решения при расчете
окупаемости в долгосрочной перспективе, учитывайте как CapEx, так и OpEx.
Например, при покупке холодильника, который будет работать в режиме 24/7,
вы обращаете внимание на показатель энергосбережения, чтобы не разориться
на электричестве. Вы готовы изначально заплатить больше, если знаете, что
общие затраты со временем будут ниже благодаря экономии на счетах за электроэнергию. Теперь возьмем в качестве примера дата-центр. Он требует исходных
затрат на приобретение оборудования (CapEx). Кроме того, создание дата-центра
подразумевает дополнительные текущие расходы (OpEx), в том числена обогрев и охлаждение, администрирование инфраструктуры, безопасность и т. д.
Принципы проектирования для оптимизации затрат
375
В типичном сценарии использования при приобретении и реализации программного обеспечения следует учитывать следующие затраты для вычисления
TCO (рис. 10.1).
Совокупная стоимость
владения
Затраты
на приобретение
и установку
Затраты
на эксплуатацию
и обслуживание
Затраты на персонал
и повышение
квалификации
Рис. 10.1. TCO для ИТ-приложения
Рассмотрим затраты более подробно. С каждым компонентом TCO связаны
следующие стандартные затраты на тиражное ПО (например, Oracle или базы
данных MS SQL).
В категорию «тиражного», или стандартного коммерческого (off-the-shelf), ПО
входят готовые, массово выпускаемые приложения, предназначенные для
широкой аудитории со схожими потребностями — в отличие от заказного,
или специализированного (custom), ПО, адаптированного для специфических
требований конкретного бизнеса или пользователя.
y
y Затраты на приобретение и установку: единовременные затраты на по-
y
купку ПО и сервисов для его развертывания. К этой категории относятся
следующие затраты:
стоимость приобретения ПО с необходимыми пользовательскими лицензиями;
затраты на оборудование, включая сервер и пространство для развертывания ПО;
затраты на реализацию, состоящие из времени и усилий на подготовку
ПО к эксплуатации;
затраты на миграцию, включая перемещение данных в новую систему.
y Затраты на эксплуатацию и обслуживание: непрерывные затраты на поддержание работы ПО для конкретного бизнес-сценария, включая следующее:
обслуживание и поддержка;
установка обновлений и патчей, часто выпускаемых вендорами для исправления любых потенциальных ошибок;
специальные изменения, адаптирующие ПО к потребностям организации;
376
Глава 10. Оптимизация затрат
затраты на поддержание физического сервера в дата-центре;
безопасность;
продление лицензий.
y
y Затраты на персонал и повышение квалификации: затраты на обучение
персонала, чтобы работники могли использовать ПО для выполнения бизнес-операций. К этой категории относятся следующие затраты:
оплата администраторов приложения;
оплата сотрудников техподдержки;
оплата функциональных и технических консультантов;
обучение и средства обучения.
Существуют разные варианты оптимизации затрат, включая подписку на продукты SaaS (Software as a Service) — такие, как платформа CRM (Customer
Relationship Management) от Salesforce. Модель SaaS в основном использует
подписку по количеству пользователей, а значит, нужно определить, получите ли вы желаемую экономию. Для большого количества пользователей
можно выбрать гибридный метод и использовать облако для управления
оборудованием по модели «инфраструктура как сервис», IaaS (Infrastructure
as a Service), устанавливая тиражное ПО. В общем случае, если программное
обеспечение не удовлетворяет вашим требованиям, вы можете создать его самостоятельно. В любом сценарии рассчитайте TCO, чтобы понять, где можно
добиться максимальной окупаемости. Рассмотрим планирование бюджета
и прогнозирование, которые помогают в управлении общими затратами и достижении окупаемости.
Планирование бюджета и прогнозирование
Каждый бизнес должен планировать свои расходы и рассчитывать окупаемость
(ROI). Планирование бюджета дает организациям и командам информацию
для управления затратами. Организации планируют долгосрочный бюджет на
срок от 1 до 5 лет, что помогает им вести бизнес на основании необходимого
финансирования. Затем бюджет распространяется на отдельные проекты и приложения. В процессе проектирования и разработки решения команда должна
учитывать доступный бюджет. Бюджет призван количественно оценить поставленные бизнесом цели. Прогнозирование предоставляет оценку того, что
делает компания.
Планирование бюджета — важная часть долгосрочного стратегического планирования, а прогнозирование предоставляет оценку на тактическом уровне для
выбора направления бизнеса. Не имея бюджета и прогноза, вы быстро собьетесь
с пути и превысите расчетные затраты на разработку и эксплуатацию приложений. Термины «бюджет» и «прогноз» могут вызвать путаницу, поэтому поясним
различия между ними (табл. 10.1).
Принципы проектирования для оптимизации затрат
377
Таблица 10.1. Различия между бюджетом и прогнозом
Параметр
Бюджет
Прогноз
Определение
Подробный финансовый план
с описанием ожидаемых доходов, расходов и распределения ресурсов за указанный
период
Обновленное предсказание
финансовой эффективности
компании на основании текущих тенденций и краткосрочных ожиданий
Период времени
Обычно планируется на долго- Более динамичен; обновляетсрочный период — например, ся регулярно (ежемесячно или
год
ежеквартально)
Частота
корректировки
Корректируется относительно
редко — например, раз в год
или при значительных изменениях
Обновляется регулярно на
основании текущей ситуации
и краткосрочных перспектив
Назначение
Используется для принятия
бизнес-решений, стратегического планирования и распределения ресурсов
Используется для принятия
обоснованных оперативных
решений и корректировок на
основании последних тенденций и предсказаний
Оценка
эффективности
Эффективность оценивается
путем сравнения запланированных и фактических затрат
и доходов
Эффективность не оценивается относительно поставленных целей. Нужен для
понимания потенциальной будущей финансовой ситуации
Примеры
Решения по реструктуризации компании, планированию
ежегодных затрат на маркетинг и целевого объема продаж за год
Корректировка штатной численности, изменение маркетинговых стратегий на основании недавних результатов,
обновление объема ожидаемых доходов
Прогноз помогает предпринять немедленные действия, в то время как бюджет
может оказаться недостижимым из-за изменений на рынке. Как показано
на рис. 10.2, текущая информация по расходам в сравнении с историческими
прогнозами может побудить вас скорректировать расходы на следующий
месяц.
Как видно из приведенного отчета, бюджет с ежемесячным размером затрат $450
будет исчерпан к концу ноября 2024 года. В данном случае прогноз помогает
действовать и управлять затратами, чтобы оставаться в рамках бюджета.
В следующем разделе рассматривается механизм повышения эффективности
затрат за счет управления потребностями и сервисами.
378
Глава 10. Оптимизация затрат
Рис. 10.2. Прогнозный отчет
Потребности и каталоги сервисов
Почти в каждой организации существует централизованная ИТ-команда, работающая с внутренними партнерами — например, с командой разработки и командами поддержки из разных бизнес-подразделений. ИТ-команда управляет
потребностями в ИТ-инфраструктуре, включая затраты на ПО, оборудование
и поддержку для управления хостингом приложений. Бизнес-партнерам часто
требуется более глубокое понимание затрат на их ИТ-сервисы. Например, команды разработки приложений зачастую совершают излишние траты на среды
разработки и тестирования, что увеличивает расходы.
Вы можете запрашивать прогнозы от разных подразделений заранее, что поможет согласовать поставки ИТ-инфраструктуры в целом. Консолидируя все
требования в одном месте, организация может экономить благодаря масштабу.
Потребности всех подразделений объединяются, что ведет к снижению цен.
Например, при использовании сервисов публичных облачных платформ (например, AWS, GCP или Azure) у компаний появляется возможность получить более
благоприятные расценки за счет закрытых ценовых соглашений (PPA, Private
Pricing Agreement) или корпоративных скидочных программ (EDP, Enterprise
Discount Program). Такие соглашения особенно выгодны для организаций
с высокими рабочими нагрузками, консолидирующих свои ресурсы у одного
Принципы проектирования для оптимизации затрат
379
облачного провайдера. Принимая на себя обязательства об определенном уровне
использования или оплаты, компании могут добиться более выгодных цен, что
ведет к значительной экономии.
y
y
Организации могут выбрать один из двух подходов:
y управление потребностями: для экономии затрат в существующих ИТсредах (где часто встречаются избыточные расходы) можно воспользоваться
подходом, основанным на потребностях. Он поможет повысить эффективность затрат в краткосрочной перспективе при введении нескольких новых
сервисов. Проанализируйте исторические данные, чтобы понять факторы,
управляющие потребностями, и случаи лишних приобретений. Разработайте
для ИТ-команды и бизнес-партнеров процесс, упрощающий понимание затрат на эксплуатацию ИТ-сервисов;
y управление каталогом сервисов: если возникает потребность в новых сервисах, а у вас слишком мало исторических данных, можно воспользоваться
подходом, основанным на сервисах. При этом подходе необходимо понимать
потребность в часто используемых сервисах и создать каталог. Например,
команда разработки запрашивает сервис Linux с базой данных MySQL для
создания среды разработки. В таком случае ИТ-команда может создать каталог сервисов, который поможет команде разработки приобрести небольшой
сервер Linux с сервером базы данных. Точно так же можно определить набор
самых распространенных сервисов и повысить детализацию затрат.
Каждый подход способствует значительной экономии как в краткосрочной, так
и в долгосрочной перспективе. Тем не менее реализовать их довольно трудно,
так как приходится изменять процессы планирования и утверждения проекта.
Финансовая и бизнес-команда должны работать согласованно и понимать
четкую взаимосвязь между ростом бизнеса и повышением ресурсоемкости
ИТ. Модель затрат должна строиться на самом эффективном подходе с объединением облачных и локальных сред, а также предложений от вендоров
тиражного ПО.
Отслеживание расходов
Чтобы получать информацию о расходах на отдельные системы, организуйте отслеживание расходов с привязкой к владельцам системы или бизнеса. Доступная
и детализированная финансовая информация помогает оценивать ROI, проводить дальнейшую оптимизацию ресурсов и сокращать издержки. Кроме того,
можно рассчитать ежемесячные затраты каждого подразделения или проекта.
Сокращение затрат — общая ответственность, и вам понадобится механизм,
который обеспечит подотчетность каждого подразделения или сотрудника.
Во многих организациях внедряют механизмы show-back (демонстрация затрат, то есть информационный отчет о затратах) или charge-back (возмещение
затрат, то есть выставление счетов подразделениям за использование средств)
для распределения ответственности за расходы между подразделениями.
380
Глава 10. Оптимизация затрат
В случае show-back информация о расходах каждого подразделения содержится в централизованном счете, но фактическая оплата при этом не взимается.
В случае charge-back каждое подразделение в организации управляет своим
бюджетом при помощи мастер-счета плательщика. С мастер-счета подразделениям компенсируются их расходы на ИТ-ресурсы исходя из фактического
потребления за месяц. Эти механизмы мотивируют каждое подразделение более
ответственно относиться к расходам.
При реализации контроля затрат в организации лучше начать с отчетов showback в качестве промежуточного этапа и переходить на схему charge-back по
мере становления организационной модели.
Чтобы сформировать сознательное отношение к расходам в каждом подразделении, настройте оповещения, чтобы команды получали сигнал о приближении
к прогнозному или бюджетному объему потребления. Создайте механизм мониторинга и управления затратами, распределяя их соответствующим образом
между инициативными сторонами. Обеспечьте открытость информации, чтобы
сформировать ответственность за расходы каждой команды. Отслеживание затрат поможет лучше понять деятельность каждой команды.
Любая рабочая нагрузка индивидуальна; используйте модель ценообразования, которая подходит для вашей рабочей нагрузки, чтобы сократить затраты.
Установите механизмы, обеспечивающие достижение бизнес-целей за счет применения лучших практик оптимизации затрат. Перерасходов можно избежать,
определив стратегию связывания подразделений с конкретными затратами
и использования метода перекрестного контроля.
Непрерывная оптимизация затрат
Если вы придерживаетесь лучших практик оптимизации затрат, то должны
хорошо соотносить затраты с текущей активностью. С течением времени всегда
можно сократить затраты для зрелых приложений, прошедших миграцию.
Оптимизацию затрат следует продолжать до тех пор, пока расходы на определение возможностей для экономии не станут выше сэкономленной суммы.
Пока этот показатель не будет достигнут, необходимо непрерывно отслеживать
расходы и искать новые возможности сокращения затрат. Один из методов —
экономить за счет исключения простаивающих ресурсов. Допустим, компания использует облачные сервисы для своих сред разработки, тестирования
и эксплуатации. Непрерывно отслеживая свои облачные расходы, компания
обнаруживает, что несколько экземпляров в среде разработки остаются недозагруженными или простаивают, особенно во внепиковые часы. Чтобы сократить затраты, компания реализует график автоматического отключения
этих экземпляров в то время, когда они не используются (например, по ночам
или в выходные). Такой подход значительно сокращает затраты компании на
облако, так как ресурсы оплачиваются только тогда, когда они задействуются.
Принципы проектирования для оптимизации затрат
381
Со временем практика выявления и устранения простаивающих ресурсов может привести к значительной экономии, позволяя компании более эффективно
распределять свой бюджет.
Чтобы сбалансировать затраты на архитектуру и ее производительность, убедитесь, что расходы на ресурсы эффективны и все ресурсы в системе загружены
(например, экземпляры серверов).
Метрики использования ресурсов, демонстрирующие аномально высокие или
низкие затраты, не должны применяться для принятия решений, так как это
может повредить бизнесу организации. Оценка метрик эффективности использования без учета контекста может привести к искаженным интерпретациям
и ошибочным решениям. Так, если брать за основу данные пиковых периодов
(к примеру «черной пятницы» для интернет-магазинов), это может привести
к выделению большого количества избыточных ресурсов. В периоды меньшей
нагрузки ресурсы окажутся недозагруженными, что экономически неэффективно. Необходимо анализировать подобные метрики с учетом контекста, чтобы
избежать ловушек и убедиться, что ресурсы распределяются разумно и в соответствии с фактической потребностью, а не на основании пиковых или нетипичных периодов использования. Это способствует предотвращению лишних
затрат и эффективному управлению ими.
Метрики уровня приложения необходимо тщательно продумать для оптимизации затрат. Например, введите политики архивации для управления
емкостью хранилища данных. Чтобы оптимизировать базу данных, проверьте
потребности в ее развертывании — например, насколько необходимо ее территориально-распределенное развертывание и соответствует ли обеспечиваемый
уровень операций ввода/вывода в секунду (IOPS) реальным потребностям.
Можно воспользоваться моделью SaaS, чтобы сократить нагрузку на администрирование и поддержку, при этом сосредоточиться на приложениях
и бизнес-целях.
Чтобы выявить пробелы и применить необходимые изменения для сокращения затрат, следует реализовать процессы управления ресурсами и контроля
изменений на протяжении жизненного цикла проекта. Они помогут организации проектировать архитектуру по возможности оптимально и экономично.
Ищите новые сервисы и функциональность, которые напрямую сокращают
затраты.
В этом разделе были рассмотрены принципы проектирования, направленные на
оптимизацию затрат, начиная с эффективного планирования бюджета до активного мониторинга затрат и непрерывных стратегий экономии. Эти принципы
очень важны для того, чтобы архитектура не только удовлетворяла требованиям
к производительности и эксплуатации, но и соответствовала финансовым целям
и организация могла получить максимальную отдачу от вложений и минимизировать лишние расходы. Рассмотрим некоторые приемы, которые помогают
оптимизировать затраты и повысить окупаемость.
382
Глава 10. Оптимизация затрат
Приемы оптимизации затрат
Компании инвестируют в технологии, чтобы получить конкурентное преимущество и продолжать быстрый рост. В условиях экономической нестабильности оптимизация затрат становится важной, но непростой задачей. Компании
тратят много времени на исследование и сокращение затрат на приобретение
и эксплуатацию оборудования и поиск поставщиков. Многие компании даже
совместно используют дата-центры, кол-центры и рабочие пространства для
экономии затрат. Иногда организации тратят больше времени на обновления,
чтобы избежать покупки нового дорогостоящего оборудования.
Организация может добиться более значительной экономии, анализируя свою
внутреннюю ИТ-архитектуру. Улучшение существующей архитектуры способно открыть перед компанией новые возможности, даже если это потребует
определенной корректировки бюджета. Рассмотрим приоритетные области,
в которых компании могут экономить средства и повышать свой доход такими
приемами, как переход в облако, упрощенная архитектура, визуализация и совместно используемые ресурсы.
Сокращение архитектурной сложности
Хотя многие организации стремятся к централизованной ИТ-архитектуре, на
практике каждое бизнес-подразделение пытается создать собственный набор
инструментов. Отсутствие общего контроля приводит к появлению множества накладывающихся друг на друга систем и несогласованности данных. ИТ-инициативы
в отдельных бизнес-юнитах ориентируются на краткосрочные цели.
В подобных ситуациях необходимо обеспечить соответствие целей подразделений долгосрочному организационному вˆидению — например, цифровой трансформацией всей организации. Кроме того, дублирование усложняет обслуживание и обновление систем. Простое определение стандартов и предотвращение
дублирования способствует сокращению затрат.
На рис. 10.3 представлена сложная архитектура (слева), в которой подразделения
работают в своих приложениях без стандартизации, из-за чего появляются приложения-дубликаты с многочисленными зависимостями, — подобные архитектуры приводят к высоким затратам и рискам. Проведение любых экспериментов
занимает много времени, что приводит к потере конкурентных преимуществ.
Стандартизация процесса, разработка архитектурных паттернов, пригодных для
повторного использования, и создание семейства общих сервисов формируют
комплексную и гибкую основу для адаптивной среды. Применяя автоматизацию
на этой основе, организации могут упрощать эксплуатацию, избегать лишних
усилий и значительно сокращать свои затраты. Подобный комплексный подход не только способствует операционному совершенству, но и повышает окупаемость, демонстрируя стратегическое совмещение архитектурных практик
с бизнес-целями для достижения оптимальной финансовой эффективности.
Приемы оптимизации затрат
383
Пользователь
Фронтенд
Фронтенд
Бэкенд
Избыточное
приложение
Монолитное
приложение
Веб-сервер
Бэкенд
База
данных
База
данных
Рис. 10.3. Архитектурная стандартизация
Прежде всего необходимо устранить дублирование и выявить возможности
повторного использования функциональности между подразделениями, чтобы
сократить сложность архитектуры. Включение этих повторно используемых
компонентов в каталог сервисов может значительно улучшить доступность
и эффективность. Каталог сервисов работает как централизованный репозиторий, в котором команды могут находить и повторно использовать заранее
определенные архитектурные паттерны, сервисы и ресурсы. В ходе gap-анализа
(анализа разрывов) существующих архитектур вы найдете множество компонентов и кода, который может повторно использоваться в рамках организации для
обеспечения бизнес-требований. Чтобы сократить сложность ИТ-архитектуры,
попробуйте найти готовое решение, которое подойдет вашему бизнесу и обес
печит окупаемость. Разработка специализированного продукта должна стать
последним вариантом, если не найдется ничего другого.
Любое новое приложение должно иметь доступный механизм интеграции для
взаимодействия с существующей системой через RESTful-архитектуру. Гармонизация дизайна пользовательских интерфейсов между приложениями позволяет
создать набор стандартных UI-пакетов, которые могут повторно использоваться
во всех новых приложениях.
Точно так же другие модули могут повторно использоваться в сервис-
ориентированном проектировании. Паттерны RESTful-архитектур рассматривались в главе 4 «Паттерны проектирования архитектур решений»; они
помогают хранить разные части программных продуктов по отдельности, но
так, чтобы они могли взаимодействовать друг с другом, образуя целостную
систему.
384
Глава 10. Оптимизация затрат
При модульном подходе каждая команда отвечает за разработку сервиса, который
может использоваться всеми командами в организации для предотвращения
дублирования. Вы как архитектор должны помочь команде создать сервисориентированную архитектуру, где каждая команда рассматривает отдельные
компоненты архитектуры как сервис, который может разрабатываться независимо. С помощью микросервисной архитектуры можно разрабатывать все
приложение по модульной схеме. Если один компонент не работает, его можно
изменить без последствий для всего приложения. Например, платежный сервис, разработанный для сбора платежей от клиентов интернет-магазина, также
может использоваться для перевода оплаты поставщикам в системе управления
поставщиками.
После создания централизованной архитектуры применение модульного
подхода способствует сокращению затрат. Расширение полномочий архитектурной команды поможет согласовать вˆидение подразделений с вˆидением
компании и поддерживать другие параллельные проекты в рамках общей
стратегии. Кроме того, это обеспечит целостность в других критически важных
сервисах, о которых часто забывают, — например, юридических, финансовых
и кадровых.
С помощью архитектурной команды можно получить превосходную обратную
связь и убедиться в том, что проекты соответствуют требованиям бизнеса.
Контролируя общую архитектуру между командами, архитектор может дать
совет относительно того, будет ли дубликат проекта, процесса или системы
соответствовать потребностям бизнеса. Централизация архитектуры снижает
сложность и уменьшает технический долг, что приводит к повышению стабильности и качества. Общая цель централизованной архитектуры заключается в повышении эффективности ИТ, поэтому эту тему стоит рассмотреть
подробнее.
Повышение эффективности ИТ
В наше время каждая компания использует и потребляет ИТ-ресурсы. На избыточные серверы, ноутбуки и программные лицензии, а также на высокую емкость
хранилища расходуются значительные средства. Лицензии — один из ресурсов,
которые иногда недоиспользуются, теряются, простаивают или устанавливаются
неправильно и требуют значительного финансирования. Централизованная
ИТ-команда может возглавить усилия по оптимизации лицензий, отслеживая
используемые и списывая лишние. Кроме того, можно добиться экономии за
счет оптовых скидок у поставщика.
Чтобы повысить эффективность ИТ, отмените проекты, которые не соответствуют требованиям, но используют дополнительное финансирование и ресурсы.
Кроме того, вы должны помогать командам следовать стратегии и осуществлять
поддержку неиспользуемых или не соответствующих ей проектов или регулярно
завершать их.
Приемы оптимизации затрат
385
y
y
y
y
y
y
y
y
y
y
Рассмотрите следующие методы оптимизации затрат.
y Проведите переоценку проектов с высокими затратами; возможно, их стоит
привести в соответствие с вˆидением бизнеса. Переработайте проекты, которые
имеют высокую бизнес-ценность, но не оказывают прямого воздействия на
ИТ-стратегию.
y Понизьте приоритеты проектов с минимальной бизнес-ценностью, даже если
они соответствуют ИТ-стратегии.
y Отмените проекты с низкой бизнес-ценностью, не отвечающие комплаенсу.
y Выведите из эксплуатации или удалите неиспользуемые приложения.
y Замените старые унаследованные системы, модернизируя их для сокращения
затрат на обслуживание.
y Избегайте дублирования проектов за счет повторного использования существующих приложений.
y По возможности консолидируйте данные и разрабатывайте интегрированную модель данных. Централизованные хранилища данных более подробно
рассматриваются в главе 12 «Инженерия данных для архитектур решений».
y Консолидируйте внешние поставки в пределах организации, чтобы сэкономить на поддержке и обслуживании.
y Консолидируйте любые системы, которые делают то же, что платежные
системы и системы управления доступом.
y Избавляйтесь от затратных, неэкономных, излишних проектов и расходов.
Перемещение в облако может стать отличным вариантом эффективного расширения ИТ-ресурсов и сокращения затрат. Провайдеры публичных облачных
платформ (таких, как AWS) предоставляют модель оплаты по мере фактического
использования ресурсов; это означает, что вы платите только за то, что реально
используете. Например, можно отключать десктопную систему разработчика
на выходные и нерабочее время, что позволит сократить затраты на рабочее
место до 70 %. Система пакетной обработки должна запускаться только для обработки заданий, после чего ее можно почти сразу же выключить. Она работает
как любой электроприбор, который выключается, когда не используется, чтобы
сэкономить расходы на электричество.
Применение автоматизации — отличный механизм повышения общей эффективности ИТ. Автоматизация помогает избавиться от дорогостоящего человеческого
труда и сокращает время выполнения повседневных рутинных задач, снижая
риск ошибок. Автоматизируйте все что возможно: выделение серверов, запуск
заданий мониторинга, обработку данных и т. д.
Принимая решение об оптимизации затрат, старайтесь выдерживать разумный
баланс для улучшения результатов. Рассмотрим пример. Если вы идете в парк
развлечений, где много интересных аттракционов, то вы согласитесь заплатить
высокую цену за вход. Если владелец парка решит снизить цену, но при этом
сократит количество интересных аттракционов, вы можете пойти в другой парк,
386
Глава 10. Оптимизация затрат
чтобы хорошо провести время. Конкуренты получат преимущество и привлекут
новых клиентов, тогда как текущий поставщик потеряет свою долю рынка. В таком случает сокращение затрат повышает риск для бизнеса, что нельзя считать
хорошим методом оптимизации затрат.
Ваши цели должны быть количественно измеримыми, а метрики должны измерять
бизнес-результаты и затраты. Цели уровней организации и команд должны соответствовать целям конечных пользователей приложения. На уровне организации
цели должны ставиться между подразделениями. На уровне команды они будут
в большей степени соответствовать конкретным системам. Например, можно установить цель уровня бизнес-подразделения для сокращения затрат на транзакцию на
10 % за квартал или на 15 % каждые шесть месяцев. Определение целей гарантирует,
что системы будут совершенствоваться на протяжении своего жизненного цикла.
А теперь посмотрим, как применять стандартизацию и управление.
Применение стандартизации и управления
Организациям нужна стратегия для анализа несоответствий и чрезмерного потреб
ления, сокращения сложности, определения рекомендаций для использования
наиболее эффективных систем и реализации процессов там, где они необходимы. Создание и внедрение этих рекомендаций помогут компаниям разработать
стандартную инфраструктуру, сократить дублирование проектов и сложность.
Чтобы реализовать рациональное управление, следует установить ограничения
ресурсов в пределах организации. Создание каталога сервисов в рамках IaC («инфраструктура как код») позволяет следить за тем, чтобы командам не выделялись
ресурсы свыше установленной для них нормы. Вам понадобится механизм, который
позволит быстро понять бизнес-требования и совершать необходимые действия.
При установлении ограничений ресурсов и определении процесса изменения
этих ограничений следует учитывать создание и вывод ресурсов из эксплуатации.
В рамках IaC вся подготовка инфраструктуры от сетей и серверов до баз
данных и сервисов приложений может определяться в файлах с кодом на
таких языках, как YAML или JSON. Эти файлы могут участвовать в системах
контроля версий, позволяя командам отслеживать изменения во времени,
возвращаться к предыдущим конфигурациям и применять одинаковые
конфигурации в разных средах, обеспечивая согласованность и сокращая
дрейф конфигураций. Для применения IaC могут использоваться такие
популярные инструменты, как Terraform, AWS CloudFormation и Ansible,
позволяющие командам определять IaC и применять эти определения для
создания или изменения инфраструктуры.
Компании обычно используют множество приложений, разрабатываемых разными командами из различных бизнес-подразделений. Определение затрат на
ресурсы на уровне приложений, подразделений или команд способствует эффективному использованию ресурсов и сокращению затрат. Ресурсную емкость
Приемы оптимизации затрат
387
можно определить на основании правильного отнесения затрат и на основе
потребностей групп, подразделений или отделов. Для организации структуры
затрат можно пользоваться тегированием ресурсов и структурированием счетов.
Как показано на рис. 10.4, счета могут структурироваться по разным подразделениям (OU, Organizational Unit): кадры, финансы, маркетинг и т. д., — при
этом каждый отдел в подразделении может иметь собственные счета. Например,
на диаграмме отдел персонала (HR) имеет разные счета для начисления зарплат
и маркетинга, тогда как в отделе финансов используются отдельные счета для
продаж и маркетинга.
Рис. 10.4. Корпоративная структура счетов для подразделений
388
Глава 10. Оптимизация затрат
В этой схеме структурирования счетов можно управлять затратами на уровне
каждого подразделения и отдела. Внедрение механизма charge-back для каждого
отдела повышает ответственность за затраты на более детализированном уровне,
что способствует их оптимизации.
Структурирование счетов помогает применять высокие стандарты безопасности
и комплаенса в организации. Так как каждый счет связывается с родительским
счетом, вы можете в значительной мере решить задачу массового использования
ресурсов поставщика, консолидируя расходы в организации.
Тегирование затрат ресурсов
Почти каждый провайдер публичных облачных платформ предоставляет готовую функциональность тегирования (tagging). В разметку можно встраивать
метаданные серверов — например, имя DNS или имя хоста для локальных сред.
Теговая разметка помогает упорядочить затраты и определить пределы емкости,
критерии безопасности и комплаенса. Она может стать отличным инструментом
для управления запасами и наблюдения за растущими потребностями в ресурсах
на каждом уровне организации.
Тегирование ресурсов становится мощной стратегией управления и оптимизации затрат в облачных вычислительных средах. Она включает назначение тегов
метаданных для облачных ресурсов (виртуальных машин, экземпляров хранилищ или баз данных) с целью их классификации и отслеживания на основании
различных критериев: проектов, сред, отделов, центров затрат.
Как видно из рис. 10.5, для получения полной видимости затрат и консолидации
между ресурсами можно пометить тегом каждый ресурс, предоставляемый на
уровне команды, что обеспечивает более детализированный контроль.
Рис. 10.5. Тегирование ресурсов для обеспечения видимости затрат
Приемы оптимизации затрат
389
На этой диаграмме мы видим стратегию тегирования, которое указывает, что
сервер предназначен для развертывания приложения (Type: AppServer) и используется командой разработки (Environment: Dev). Владельцем сервера
является отдел маркетинга (Department: Marketing) финансового подразделения (Busines Unit: Finance). При таком подходе организация может получить
детализированную информацию о расходах, и команды будут более экономны.
Впрочем, можно применить механизм show-back на уровне команд и механизм
charge-back на уровнях отделов и подразделений.
Можно внедрить собственный механизм тегирования, который позволит присоединить к любому ресурсу имя и значение (например, имя ресурса и имя
владельца). На рис. 10.6 представлены затраты, отсортированные по тегу
aws:createdBy; этот список помогает определить затраты на каждый ресурс,
автоматически вычисляемые AWS.
Рис. 10.6. Дашборд расходов на ресурсы для заданного тега
Руководителям бизнеса необходимо оценивать общие требования для создания
эффективных ИТ-архитектур. Для разработки надежной ИТ-архитектуры требуется сотрудничество между функциональными командами, чтобы установить
систему управления и четко определить области ответственности. Кроме того,
следует разработать стандарт для анализа архитектуры, задать основные исходные параметры для любых новых инициатив и провести разъяснение процесса,
чтобы обеспечить соответствие системы архитектурным нормам и выявить возможности для усовершенствования.
Привлеките всех стейкхолдеров к обсуждению затрат и использования ресурсов.
Финансовый директор и владельцы приложений должны понимать потребление
ресурсов и варианты приобретений. Руководители отделов должны понимать
общую бизнес-модель и процесс ежемесячного выставления счетов. Это поможет
задать направление для подразделений и компании в целом.
390
Глава 10. Оптимизация затрат
Убедитесь, что внешние поставщики действуют в соответствии с вашими
финансовыми целями и могут корректировать свои модели участия. Поставщики должны представить анализ затрат для любого приложения, которым
они владеют и которое разрабатывают. Каждая команда в организации должна
быть способна перевести факторы бизнеса, затрат и использования ресурсов из
плоскости управления в действия по настройке системы, чтобы приложения
могли достигать целей компании.
Мониторинг затрат и отчеты
Точные данные о затратах помогают определить прибыльность подразделений
и продуктов. Отслеживание затрат помогает распределять ресурсы для повышения окупаемости. Понимание затрат помогает управлять расходами бизнеса.
Чтобы оптимизировать затраты, необходимо знать паттерны расходов в организации. Следует также иметь представление о расходах ИТ во времени, чтобы
определить возможности экономии. Для оптимизации затрат и понимания ее
последствий можно создать наглядное представление трендов затрат с историческими данными и прогнозами для разных ресурсов и отделов в организации.
Следует собирать все необходимые данные, регистрировать все точки данных,
анализировать их в ходе мониторинга и создавать наглядные отчеты.
y
y
y
y
Чтобы выявить возможности для экономии, понадобится подробная информация об использовании рабочих ресурсов. Оптимизация затрат зависит от
вашей способности прогнозировать будущие расходы и соотносить затраты с использованием ресурсов с прогнозами. Ниже перечислены основные сценарии,
в которых понадобится визуализация данных:
y определение самых крупных инвестиций в ресурсы;
y анализ и понимание расходов и данных по использованию ресурсов;
y бюджет и прогнозирование;
y получение оповещений при превышении бюджетных или прогнозных порогов.
На рис. 10.7 показан отчет о стоимости ресурсов в AWS за шесть месяцев. Из
визуализации видно, что на облачный вычислительный сервер EC2, представленный пятым столбцом за каждый месяц, приходились самые высокие затраты
с мая по июль 2023 года. Так как подразделение постоянно видит на диаграмме
высокие затраты, системному администратору необходимо вплотную заняться
оптимизацией затрат и выявлением простаивающих ресурсов. Администратор
остановил эти серверы EC2, что привело к снижению затрат в августе и их полному исключению начиная с сентября.
Предыдущий отчет помог владельцам бизнеса понять паттерны затрат и применить реактивный подход к управлению затратами. Реактивный подход породил скрытые затраты, которые оставались незамеченными за рассматриваемый
период. С проактивным подходом прогноз помог владельцам бизнеса принять
упреждающее решение.
Приемы оптимизации затрат
391
Рис. 10.7. Отчет о стоимости ресурсов и их использовании по сервисам
Отчет на рис. 10.8 показывает диапазоны ежемесячных расходов (заполненные
прямоугольники) и прогнозируемых затрат (пустые прямоугольники). Из отчета следует, что затраты с большой вероятностью возрастут за ближайшую
пару месяцев, и можно принять меры к тому, чтобы понять факторы затрат
и контролировать их.
Рис. 10.8. Отчет о затратах с прогнозом
392
Глава 10. Оптимизация затрат
Мониторинг затрат относительно бюджета может привести к дополнительным
проактивным мерам для контроля затрат. Выдача оповещения при расходовании
определенной части бюджета (50 или 80 %) поможет проанализировать и скорректировать текущие затраты.
В отчете на рис. 10.9 можно наглядно сравнить текущие затраты с бюджетными; год назад они были достаточно высокими. На основании этого отчета
ИТ-администраторы могут принять меры по оптимизации затрат и их приведению в границы ежемесячного бюджета.
Рис. 10.9. Отчет о затратах и бюджете
Отчеты о затратах и бюджете позволяют контролировать затраты, действуя
проактивно. Соотнесение фактических затрат с бюджетами и прогнозами предоставляет широкие возможности для повседневного контроля затрат.
Также можно настроить оповещение при достижении фактическими затратами
определенного порога в бюджете или прогнозе. Такое оповещение отправляется
по электронной почте или SMS и указывает на необходимость проактивного
контроля над затратами.
На рис. 10.10 показано, что оповещение отправляется при превышении оценочными затратами порога $500. Можно настроить несколько оповещений,
уведомляющих, что затраты достигли, скажем, порога $300 и $400.
Один из способов контроля затрат — это оптимальное выделение ресурсов (rightsizing) с мониторингом ресурсов и отправкой оповещений при чрезмерной или
недостаточной загруженности. Анализ ресурсов может выполняться с помощью
таких средств мониторинга, как Splunk, CloudWatch или специализированные
журналы, а для их оптимального выделения помогут специализированные
Приемы оптимизации затрат
393
Рис. 10.10. Оповещения на основе фактических затрат
метрики — например, использование памяти приложениями. Низкое потребление
ресурса может стать критерием для выявления возможностей сокращения затрат.
Например, можно анализировать и отслеживать загрузку процессора и памяти,
пропускную способность сети и количество подключений к приложению.
y
y
Будьте осторожны при изменении масштабов инфрастуруктуры, чтобы это
не отразилось на качестве пользовательского опыта. Назовем рекомендуемые
лучшие практики для оптимального выделения ресурсов.
y Позаботьтесь о том, чтобы мониторинг отражал опыт конечных пользователей. Выберите правильный период времени. Например, метрики производительности должны покрывать 99 % пользовательского времени на
запрос-ответ, а не просто среднее время ответа.
y Выберите подходящий цикл мониторинга: каждый час, день или неделю.
Например, при проведении ежедневного анализа вы можете упустить
394
Глава 10. Оптимизация затрат
y
y
еженедельный или ежемесячный цикл повышенной нагрузки и выделить
недостаточно ресурсов для системы.
y Сравнивайте затраты на изменения с экономией. Возможно, вам придется
провести дополнительное тестирование или привлечь ресурсы для изменения масштабов. Анализ затрат и выгод поможет в распределении ресурсов.
y Сверяйте нагрузку на приложение с бизнес-требованиями. Например,
посмотрите, сколько пользовательских запросов вы ожидаете получать
к концу месяца или во время пиковой нагрузки. Выявление и оптимизация
несоответствий в нагрузке поможет с сокращением расходов. Используйте
подходящий инструмент, который учитывает все измерения, от экономии до загруженности системы и влияния изменений на взаимодействия
с пользователями, затем используйте отчеты, чтобы понять, как изменения
затрат влияют на окупаемость бизнеса. Публичные облачные платформы
применяют другую модель ценообразования, часто с оплатой по фактическому использованию.
При использовании облачных ресурсов необходимо действовать очень аккуратно,
так как каждая секунда увеличивает затраты, и упущения в оптимизации и мониторинге затрат могут обойтись дорого. В следующем разделе тема оптимизации
затрат на публичных облачных платформах рассматривается более подробно.
Оптимизация затрат на публичных
облачных платформах
Публичные облачные платформы — такие, как AWS, Microsoft Azure и GCP —
предоставляют отличные возможности оптимизации затрат с моделью оплаты
по фактическому использованию. Эта модель позволяет клиентам заменить
капитальные расходы (CapEx) переменными, оплачивая ИТ-ресурсы по мере
потребления. Операционные расходы (OpEx) обычно снижаются вследствие
экономии на объеме. Может быть экономически эффективно получать преимущество от снижения цен пропорционально времени работы в облаке. Другое
преимущество заключается в том, что с облачным провайдером (таким, как AWS)
вы получаете готовые дополнительные инструменты и функциональность для
более адаптивной архитектуры.
При определении модели для структуры облачных затрат необходим другой
подход, так как она отличается от традиционных моделей затрат, которые десятилетиями использовались большинством компаний. В облаке вся инфраструктура
находится прямо под рукой, что требует большей степени контроля и регулирования. Облачные платформы предоставляют инструменты для рационального
управления затратами и систематизации. Например, в AWS можно установить
ограничения, чтобы команда разработки не могла использовать более 10 серверов, а команде эксплуатации выделяется необходимое количество серверов
и баз данных с буфером.
Оптимизация затрат на публичных облачных платформах
395
Все ресурсы связываются с учетными записями в облаке, что позволяет легко
отслеживать и контролировать их нагрузку. Кроме того, вы получаете инструменты сбора данных по разным ИТ-ресурсам и предоставления рекомендаций.
Как показано на рис. 10.11, AWS Trusted Advisor обходит все ресурсы в учетной
записи и предлагает рекомендации по экономии в зависимости от степени их
использования.
Рис. 10.11. Рекомендации по снижению затрат от AWS Trusted Advisor
На скриншоте видно, что AWS Trusted Advisor обнаружил простаивающий
балансировщик нагрузки и рекомендует отключить его, чтобы сократить ежемесячные затраты до $40. Дальнейшие проверки обнаружили Lambda-функцию
с высокой частотой ошибок; ее необходимо исправить для сокращения затрат.
Облачная платформа может предоставить отличные возможности для экономии.
Для начала можно создать гибридное облачное решение и установить в нем связь
между локальным дата-центром и облаком. Серверы разработки и тестирования
можно перенести в облако, чтобы определить структуру затрат и потенциальную
экономию. Когда вы настроите рациональное управление затратами в облаке,
переходите к переносу других рабочих нагрузок на основании анализа затрат
и выгод. При этом необходимо оценить рабочую нагрузку, понять, можно ли
переместить ее в облако, и если можно — определить стратегию. Облачная
миграция рассматривалась в главе 3 «Миграция на облачные платформы и проектирование облачных архитектур».
Провайдеры публичных облачных платформ также предоставляют управляемые
сервисы, избавляя от любых затрат на обслуживание инфраструктуры и лишних расходов на настройку оповещений и мониторинга. Управляемый сервис
396
Глава 10. Оптимизация затрат
сокращает общую стоимость владения за счет сокращения затрат с повышением
уровня внедрения сервиса.
Публичные облачные платформы предлагают планы экономии или зарезервированные экземпляры, которые позволяют организациям принять обязательства
по определенному уровню использования в обмен на значительно более низкую
цену по сравнению с тарификацией по требованию. На основании анализа данных
использования ресурсов организации могут принимать обоснованные решения
о приобретении этих планов, приводя свои обязательства в соответствие с фактическими шаблонами использования для максимальной экономии.
Внедрение планов экономии в стратегию оптимизации облачных затрат позволяет организациям соблюдать баланс между гибкостью и эффективностью
затрат. Они могут сохранить адаптивность модели оплаты по фактическому использованию для переменных рабочих нагрузок, но при этом получить прибыль
благодаря планам экономии для прогнозируемого, стабильного использования,
что гарантирует эффективную оптимизацию их облачных расходов.
Термином «зеленые ИТ» (Green IT) обозначается экологически ответственное
и экологически чистое использование компьютеров и их ресурсов. Оно охватывает такие практики, как сокращение энергопотребления, минимизация
электронных отходов и проектирование дата-центров с меньшим потреблением
энергии. Эта тема более подробно рассматривается в следующем разделе.
Зеленые ИТ и их влияние на затраты
y
y
y
Зеленые ИТ (или зеленые вычисления) подразумевают изучение и практику
использования компьютеров и ИТ-ресурсов более эффективным и экологически
устойчивым образом. Практики зеленых ИТ значительно влияют на затраты по
нескольким направлениям.
y Энергетическая эффективность: использование энергетически эффективного
оборудования и практик может сократить энергопотребление дата-центров
и ИТ-инфраструктуры, что приводит к значительной экономии расходов на
электричество. Например, использование оборудования стандарта Energy
Star или оптимизация планировки дата-центров для охлаждения может понизить расходы на энергопотребление.
y Виртуализация: виртуализация серверов и хранилища может привести
к сокращению потребностей в физическом оборудовании. Таким образом
сокращаются энергопотребление и затраты, связанные с охлаждением, и минимизируется пространство, необходимое для дата-центров.
y Облачные вычисления: переход на облачные сервисы может быть более энергоэкономичным, чем содержание локальных дата-центров. Облачные провайдеры
часто предлагают варианты экономии за счет объема, а их дата-центры более
современны, эффективны и экологичны. Благодаря этому можно снизить расходы на электроэнергию и охлаждение, а также сократить углеродный след.
Зеленые ИТ и их влияние на затраты
397
y
y Переработка и повторное использование оборудования: правильно органи-
y
y
y
y
y
y
зованная переработка и повторное использование ИТ-оборудования могут
способствовать экономии. Компании могут окупить часть своих исходных
вложений за счет переработки или продажи старого оборудования. Кроме того,
восстановленное оборудование может обойтись значительно дешевле нового.
y Удаленная работа: переход на модель удаленной работы сокращает необходимость в офисах, энергопотреблении и затратах на доставку работников.
Это может привести к прямой и косвенной экономии затрат для организации
и работников с одновременной пользой для среды.
y Электронный документооборот: сокращение расхода бумаги за счет внедрения электронного документооборота может способствовать экономии затрат
на бумагу, печать и хранение, а также пользе для окружающей среды за счет
снижения бумажных отходов.
y Приобретение устойчивых ИТ-ресурсов: выбор поставщиков и продуктов,
уделяющих особое внимание устойчивости, может способствовать экономии
затрат в долгосрочной перспективе. Продукты, спроектированные с расчетом
на большую надежность или с расширенными гарантиями, могут требовать
более высоких исходных затрат, но иметь более низкую совокупную стоимость
владения с течением времени.
y Оптимизация обслуживания: регулярные обслуживание и обновление могут
продлить жизнь ИТ-оборудования, откладывая необходимость в заменах
и сокращая объем электронных отходов.
y Утилизация ИТ-ресурсов: эффективное управление утилизацией ИТресурсов может сократить затраты на обработку отходов и обеспечить соответствие экологическим нормативам, чтобы избежать возможных штрафов.
y Углеродные кредиты: сокращая углеродосодержащие выбросы за счет применения зеленых ИТ-практик, организации могут зарабатывать углеродные
кредиты, которые можно продавать или обменивать. Таким образом обес
печивается потенциальный канал поступления доходов или экономии на
углеродных налогах.
Зеленые ИТ могут способствовать значительной экономии в организациях за
счет сокращения энергопотребления, минимизации отходов, оптимизации использования оборудования и улучшения общей устойчивости. Такая экономия
часто компенсирует исходные вложения, необходимые для реализации инициатив зеленых ИТ. В следующем разделе вы узнаете, как облачные провайдеры —
такие, как AWS — способствуют внедрению зеленых ИТ в организации.
Размещение экономичных и зеленых приложений в AWS
Внедрение зеленых ИТ с участием AWS основано на преимуществах, которые
дает облачная инфраструктура в части экологии и экономической эффективности.
AWS предоставляет сервисы, поддерживающие инициативы зеленых ИТ (бессерверные архитектуры, энергоэкономичные дата-центры, средства оптимизации
398
Глава 10. Оптимизация затрат
ресурсов и т. д.). AWS проактивно поддерживает зеленые ИТ и цели устойчивости
через различные инициативы и сервисы, которые позволяют клиентам сокращать
свой углеродный след и оптимизировать использование энергии.
В среде AWS существует клиентский инструмент для определения углеродного
следа, показанный на рис. 10.12. Он предоставляет визуализации исторических данных по углеродным выбросам, тенденциям выбросов в ходе эволюции
AWS, оценки выбросов, предотвращенных за счет использования AWS вместо
локальных дата-центров, и прогнозирование выбросов на основании текущего
использования.
Рис. 10.12. Отчет об углеродном следе
В представленном отчете приводятся данные об углеродном следе за последние два года; в отчет включены данные о потреблении углеродных выбросов
и экономии. Углеродный след изменится по мере перехода AWS на 100 % возоб
новляемой энергии к 2025 году и к 2040-му станет нулевым.
AWS имеет достаточно подробные рекомендации по созданию экологически
устойчивых архитектур. Дополнительную информацию можно найти
в описании фреймворка AWS Well-Architected Framework на странице https://
docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainabilitypillar.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 и эффективное управление ресурсами сочетаются с целями компании по
оптимизации затрат и устойчивости.
Итоги
Оптимизация затрат — это непрерывный процесс, который начинается
с первых дней жизни приложения, от доказательства жизнеспособности
концепции (PoC) и до реализации и обслуживания продукта после выпуска.
Необходимо непрерывно анализировать архитектуру и возможности для сокращения затрат.
В этой главе вы узнали о принципах проектирования для оптимизации затрат. Прежде чем принимать решения о покупке, рассмотрите совокупную
стоимость владения для всего жизненного цикла программного продукта или
оборудования. Планирование бюджета и отслеживание прогнозов помогает
поддерживать оптимизацию затрат. Всегда отслеживайте свои затраты и ищите
возможности их непрерывной оптимизации за счет управления потребностями, но так, чтобы это не отражалось на взаимодействии с пользователями или
бизнес-ценности.
Вы узнали о методах оптимизации затрат, включая сокращение архитектурной
сложности за счет упрощения корпоративной архитектуры и создания стандарта,
которому могут следовать все остальные. Желательно избегать дублирования
в архитектуре, выявляя и консолидируя простаивающие и дублирующиеся
ресурсы, а также обсуждать с вендорами предоставление скидки за объем. Применяйте стандартизацию в масштабах организации, чтобы ограничить приобретение ресурсов, и разработайте стандартную архитектуру. Отслеживание данных
фактических затрат в сравнении с бюджетом и прогнозом поможет активно
влиять на текущую ситуацию. Вы узнали об отчетах и оповещениях, которые
помогают контролировать затраты. Также была рассмотрена оптимизация затрат
в облаке, которая обеспечивает дополнительные возможности для оптимизации.
Устойчивость — еще один важный параметр современных рабочих нагрузок
Итоги
401
в ИТ; вы узнали, как на затраты влияют зеленые ИТ. Также была рассмотрена
тема создания и отслеживания потребления зеленых ИТ в AWS.
Автоматизация и адаптивность — важные факторы, повышающие эффективность
использования ресурсов, и методология DevOps позволяет в значительной мере
автоматизировать работу. В следующей главе вы узнаете о компонентах DevOps
и стратегиях эффективного развертывания рабочей нагрузки с максимальной
автоматизацией.
ГЛАВА 11
DEVOPS И ФРЕЙМВОРК
АРХИТЕКТУРЫ РЕШЕНИЙ
В предыдущей главе были рассмотрены методы создания архитектуры с учетом
затрат и методы непрерывной оптимизации затрат без ущерба для производительности. Автоматизация и совместная работа команд играют ключевую роль
в разработке надежных приложений и снижении затрат. В этой главе рассматривается DevOps — методология, способствующая совместной работе команд
разработки (Dev) и эксплуатации (Ops) одновременно с автоматизацией процессов развертывания и мониторинга приложения.
В традиционных средах команда разработки и команда ИТ-эксплуатации работают изолированно. Команда разработки собирает требования у владельцев
бизнеса и разрабатывает приложения. Системные администраторы отвечают
исключительно за эксплуатацию и соблюдение требований к доступности. Эти
команды обычно мало взаимодействуют в течение жизненного цикла разработки,
и редко понимают процессы и потребности друг друга.
Каждая команда использует свои инструменты, процессы и решения с избыточностью, что иногда приводит к конфликтам. Например, команды разработки
и контроля качества (QA) могут протестировать сборку с конкретным патчем
операционной системы. Однако команда эксплуатации развертывает ту же
сборку в продакшен-среде на другой версии ОС, что приводит к проблемам
и нарушению сроков.
DevOps — методология, поощряющая сотрудничество и координацию между
командами разработки и эксплуатации для непрерывной поставки продуктов
или сервисов. Этот подход особенно эффективен в организациях, где команды
зависят от разных приложений, инструментов, технологий, платформ, баз данных, устройств и т. д. в процессе разработки или поставки продукта либо сервиса.
Хотя существуют разные подходы к культуре DevOps, все они направлены на
достижение общей цели. Суть DevOps заключается в поставке продукта или
сервиса в кратчайшие сроки за счет повышения операционного совершенства
через разделение обязанностей.
Знакомство с DevOps
403
Безопасность входит в число главных приоритетов любого приложения, а инциденты безопасности могут иметь серьезные последствия для бизнеса. Несмотря
на это, на этапе развертывания безопасность рассматривается как следствие процесса развертывания и отдельная обязанность, за которую отвечает реактивно
команда безопасности (Sec).
Внедрение безопасности как критически важного параметра DevOps может достигаться реализацией методологии DevSecOps. Суть DevSecOps заключается
в интеграции безопасности в начале и на протяжении всего жизненного цикла
разработки ПО, что помогает преодолеть изоляцию и наладить совместную
работу между командами разработки, эксплуатации и безопасности. DevSecOps
помогает добиваться результатов без ущерба для качества, надежности, стабильности, устойчивости или безопасности.
y
y
y
y
y
y
y
y
y
y
В этой главе рассматриваются следующие темы.
y Знакомство с DevOps.
y Компоненты DevOps.
y Непрерывная интеграция / непрерывное развертывание (CI/CD).
y DevSecOps в безопасности.
y Объединение DevSecOps с CI/CD.
y Реализация стратегии CD.
y Реализация непрерывного тестирования в пайплайне CI/CD.
y Использование инструментов DevOps для CI/CD.
y Реализация лучших практик DevOps.
y Построение DevOps и DevSecOps в облаке.
К концу этой главы вы узнаете о важности DevOps для развертывания, тестирования и безопасности приложений. Кроме того, вы познакомитесь с лучшими
практиками DevOps и DevSecOps, а также с другими инструментами и методами
реализации.
Знакомство с DevOps
В DevOps команды разработки и эксплуатации совместно работают на этапах
сборки и развертывания жизненного цикла программного продукта, разделяя
ответственность и предоставляя непрерывную обратную связь. Сборки программного продукта часто тестируются на этапе сборки в средах, сходных с продакшен-средой, что делает возможным раннее выявление дефектов.
Методология DevOps сочетает культуру и практики. Она требует, чтобы
организация изменила свою культуру, ломая барьеры между всеми командами в жизненном цикле разработки и поставки продукта. DevOps не сводится
к разработке и эксплуатации: методология задействует всю организацию,
включая руководство, владельцев бизнеса/приложений, инженеров по контролю качества (QA), релиз-менеджеров, команду эксплуатации и системных
администраторов.
404
Глава 11. DevOps и фреймворк архитектуры решений
Скорость позволяет организациям опережать конкурентов и быстро отвечать
на требования пользователей. Хорошие практики DevOps поощряют более эффективную совместную работу инженеров-разработчиков с профессионалами
в области эксплуатации. Результатом становится улучшение совместной работы
и коммуникации, что сокращает время вывода продуктов на рынок, повышает
надежность выпуска, качество кода и поддержки.
Иногда выясняется, что разработкой и эксплуатацией приложения занимается
одна и та же команда инженеров на протяжении всего жизненного цикла приложения. Такая команда должна иметь набор навыков, не ограниченных одной
функцией. Команды тестирования и безопасности также могут более тесно сотрудничать с командами разработки и эксплуатации с первых дней работы над
приложением до его запуска.
Разработчики получают выгоду от обратной связи, предоставляемой командами
эксплуатации, и создают стратегии тестирования и развертывания. Системным
администраторам не приходится реализовывать дефектные или не прошедшие
тестирование продукты в продакшен-средах, поскольку они участвуют в создании
этих продуктов. Так как все ключевые участники жизненного цикла разработки
сотрудничают друг с другом, они также могут оценить инструменты, которые
планируется использовать на каждом этапе процесса, проверить совместимость
между устройствами и определить, могут ли какие-либо инструменты совместно
использоваться разными командами.
DevOps набирает популярность как предпочтительная культура эксплуатации,
особенно в организациях, использующих облачные технологии или распределенные вычисления. Рассмотрим некоторые преимущества DevOps и разберемся,
почему эта методология важна для рабочей нагрузки приложения.
Преимущества DevOps
Целью DevOps является модель непрерывной интеграции / непрерывного развертывания (CI/CD), которая может использоваться для обеспечения повторяемости, надежности, стабильности, устойчивости и безопасности жизненного
цикла разработки. Эти характеристики модели помогают улучшить операционную эффективность. Для достижения этой цели команды сотрудничают
и участвуют в процессе разработки и поставки. Все члены технических команд
должны иметь опыт использования процессов и инструментов, задействованных
в пайплайне разработки.
Сложившийся процесс DevOps имеет ряд преимуществ, представленных на
рис. 11.1.
y
Вот более подробный разбор преимуществ DevOps.
y Скорость: ускоренный выпуск новой функциональности продукта помогает
адаптироваться к меняющимся бизнес-потребностям клиентов и расширить
y
y
y
y
y
y
y
y
y
y
Знакомство с DevOps
405
долю рынка. Модель DevOps позволяет организациям быстрее добиться
результатов.
Быстрая поставка: процессы DevOps способствуют повышению эффективности за счет автоматизации сквозных пайплайнов, от сборки кода до развертывания и запуска рабочей версии. Быстрая поставка позволяет оперативнее
внедрять инновации, а ускорение выпуска исправлений ошибок и новой
функциональности дает возможность получить конкурентное преимущество.
Надежность: процессы DevOps предоставляют проверки для обеспечения
качества продукта и безопасности быстрых обновлений приложения. Такие
практики DevOps, как CI и CD, внедряют автоматизацию тестирования
и проверки безопасности, улучшая опыт взаимодействий с конечным пользователем.
Масштабируемость: методология DevOps помогает масштабировать инфраструктуру и приложение под конкретные потребности за счет повсеместного
применения автоматизации.
Сотрудничество: модель DevOps формирует культуру владения, где команды
учитывают последствия своих действий. Команды разработки и эксплуатации
работают совместно по модели разделяемой ответственности. Сотрудничество
упрощает процессы и повышает эффективность.
Безопасность: в адаптивной среде частые изменения требуют строгих проверок безопасности. Модель DevOps автоматизирует лучшие практики
безопасности и комплаенса, обеспечивает их мониторинг и автоматизацию
исправлений.
Сотрудничество
Масштабируемость
Безопасность
Преимущества DevOps
Скорость
Надежность
Быстрая поставка
Рис. 11.1. Преимущества DevOps
406
Глава 11. DevOps и фреймворк архитектуры решений
Команды принимают на себя полную ответственность за сервисы, которые они
создают, часто за пределами традиционных рамок своих ролей, и учатся мыслить
с точки зрения клиента для решения любых проблем.
Рассмотрим основные составляющие процессов DevOps.
Составляющие DevOps
y
y
y
y
Инструменты и автоматизация DevOps сводят воедино разработку и системные
операции. Ниже перечислены ключевые компоненты практики DevOps:
y CI/CD;
y непрерывный мониторинг и улучшения;
y инфраструктура как код;
y управление конфигурацией.
Общее для всех элементов — их автоматизация. В автоматизации могут использоваться скрипты, шаблоны и другие инструменты. В развитой среде 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 и фреймворк архитектуры решений
Репозиторий артефактов
Конфигурация
зависимостей
Сборка пакета
Создание
Двоичные файлы сборки
Отправка
Тестирование
конфигурации
кода
Коммит в Git
Контроль версий
Пользователь
Извлечение
кода
Сервер CI
Сервер развертывания среды
тестирования/разработки/
эксплуатации
Репозиторий кода
Успешная сборка/отправка отчета об
ошибке разработчику
Рис. 11.3. CI/CD для DevOps
Надежный пайплайн CD также автоматизирует предоставление инфраструктуры
для сред тестирования и продакшен и делает возможным мониторинг и управление этими средами. CD не означает, что каждое изменение, сохраняемое разработчиком, попадет в рабочую версию, — а лишь то, что каждое изменение готово
к этому. Когда изменения тестируются в промежуточной среде, процесс ручного
утверждения запускает и дает «зеленый свет» для развертывания на продакшен.
Таким образом, в практике CD развертывание на продакшен становится бизнесрешением и автоматизируется с использованием инструментов.
Непрерывный мониторинг и улучшения
Непрерывный мониторинг позволяет оценить, как производительность приложений и инфраструктуры влияет на клиента. Анализ данных и журналов
помогает понять, как изменения в коде отразятся на пользователях.
Активный мониторинг исключительно важен в эпоху сервисов, работающих
в режиме 24/7, и постоянных обновлений в приложениях и инфраструктуре.
Составляющие DevOps
409
Вы можете организовать активный мониторинг сервисов, настраивая оповещения и выполняя анализ в реальном времени. Существуют различные метрики,
которые могут отслеживаться для контроля и улучшения практики DevOps.
y
y
y
y
y
y
y
Примеры DevOps метрик.
y Объем изменений: количество разработанных пользовательских историй,
количество строк нового кода, количество исправленных ошибок.
y Частота развертывания: насколько часто команда развертывает приложение.
В общем случае метрика должна оставаться стабильной или демонстрировать
восходящую тенденцию.
y Время от разработки до развертывания: анализ периода времени от начала
цикла разработки до завершения развертывания поможет выявить неэффективности на промежуточных этапах цикла выпуска.
y Процент неудачных развертываний: процент неудачных развертываний,
включая количество развертываний, приводящих к нарушению работоспособности, должен быть низким. Эту метрику следует рассматривать
в сочетании с объемом изменений. Если объем изменений невелик, а количество развертываний со сбоем высоко, проведите анализ потенциальных
точек сбоя.
y Доступность: отслеживайте, какое количество выпусков вызвало сбои, которые могли привести к нарушению соглашений об уровне обслуживания
(SLA). Каково среднее время неработоспособности приложения?
y Объем жалоб клиентов: количество тикетов, открытых клиентами, характеризует качество приложения.
y Процентное изменение количества пользователей: количество новых
пользователей, регистрирующихся для использования приложения, и сопутствующее повышение трафика могут помочь при масштабировании
инфраструктуры в соответствии с рабочей нагрузкой.
После развертывания сборки в рабочей среде необходимо вести мониторинг
эффективности приложения. Рассмотрим практику «инфраструктура как код»
(IaC) более подробно.
Инфраструктура как код
Приобретение инфраструктуры, управление ею и даже списание устаревшей —
процессы, требующие участия человека. Более того, повторные попытки ручного создания и изменения сред могут приводить к ошибкам. Чем бы человек
ни руководствовался, прошлым опытом или хорошо документированными
инструкциями, по статистике он склонен ошибаться.
Задачу создания готовой среды можно автоматизировать. Автоматизация задач может упростить выполнение однообразных операций и позволит создать
значительную ценность без приложения особых усилий.
410
Глава 11. DevOps и фреймворк архитектуры решений
В рамках IaC инфраструктура может определяться с помощью шаблонов.
Один шаблон может описывать как часть среды, так и всю среду. Что еще
важнее, шаблон может использоваться повторно для того, чтобы создать ту
же среду заново.
Создание и управление инфраструктурой в IaC осуществляется в форме кода.
Модель IaC упрощает взаимодействие с инфраструктурой на программном уровне в масштабе и помогает избежать человеческих ошибок за счет автоматизации
конфигурирования ресурсов. При таком подходе можно работать с инфраструктурой так же, как с кодом, и использовать инструменты для работы с кодом. Так
как управление инфраструктурой также осуществляется из кода, приложение
может развертываться с использованием стандартизированного метода, а любые
исправления и версии могут обновляться без ошибок.
Среди популярных скриптовых инструментов IaC можно выделить Ansible,
Terraform, Azure Resource Manager, Google Cloud Deployment Manager, Chef,
Puppet, AWS Cloud Development Kit (CDK) и AWS CloudFormation.
Ниже приведен фрагмент кода сервиса AWS CloudFormation, предоставляющего
поддержку IaC для автоматизации инфраструктур на облачной платформе 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, и пользователь может
выбрать имя хранилища, как показано ниже.
Рис. 11.4. IaC с использованием AWS CloudFormation
После выполнения кода создается бакет Amazon S3, который можно увидеть
на вкладке Resources.
Рис. 11.5. Автоматизированное создание хранилища объектов AWS S3
с использованием AWS CloudFormation
412
Глава 11. DevOps и фреймворк архитектуры решений
Разные команды могут использовать приведенный код для создания хранилища
Amazon S3 любого объема. Так как данные чрезвычайно важны, администратор
выбрал добавление бакета “DeletionPolicy”: “Retain”; это гарантирует, что
хранилище не будет удалено при отключении инфраструктуры, а данные останутся в безопасности.
Теперь вы знаете, как реализовать стандартизацию и согласованность данных с использованием методологии IaC. Управление конфигурацией — еще один жизненно
важный аспект процесса DevOps, который мы рассмотрим в следующем разделе.
Управление конфигурацией
Управление конфигурацией (CM, configuration management) — это процесс
автоматизированной стандартизации конфигураций ресурсов во всей инфраструктуре и приложениях. Такие инструменты CM, как Chef, Puppet и Ansible,
помогут управлять IaC и автоматизировать большинство задач системного
администрирования, включая предоставление ИТ-ресурсов, настройку их конфигурации и управление ими.
Автоматизируя и стандартизируя конфигурации ресурсов на этапах разработки,
сборки, тестирования и развертывания, можно обеспечить целостность конфигурации и избавиться от ошибок, обусловленных неверной конфигурацией. CM
также может повысить эффективность эксплуатации, позволяя автоматически
развернуть одну конфигурацию на сотнях серверов простым нажатием кнопки.
CM также может использоваться для развертывания изменений в конфигурациях.
Хотя настройки системной конфигурации также могут храниться в реестре или
базах данных, приложение CM наряду с хранением позволяет организовать
управление версиями. CM также представляет возможность отслеживания
и аудита изменений конфигурации. При необходимости даже можно поддерживать несколько версий конфигурации для разных версий продукта.
Инструменты CM включают машину-контроллер, управляющую серверными
узлами. Например, основное приложение Chef устанавливается на машинеконтроллере, а на каждом сервере, которым надо управлять, устанавливается
клиентское приложение-агент. Puppet работает по аналогичной схеме с централизованным сервером. Ansible же использует децентрализованный подход, который не требует установки агентского программного обеспечения на
серверных узлах.
В табл. 11.1 приведено обобщенное сравнение популярных инструментов управления конфигурацией.
Инструменты CM предоставляют специализированный язык и набор функций
для автоматизации. Освоение некоторых инструментов требует на начальной
стадии значительных усилий. В AWS имеются платформа OpsWorks для
управления Chef и Puppet в облаке, а также различные средства автоматизации
управления ИТ-инфраструктурой.
Составляющие DevOps
413
Таблица 11.1. Сравнение популярных инструментов CM
Ansible
Puppet
Chef
Механизм
Машина-контроллер применяет изменения к серверам
с использованием
SSH (Secure Shell)
Ведущий узел синхронизирует изменения
с узлами Puppet
Рабочая станция
Chef ищет изменения на серверах
Chef и отправляет их
узлу Chef
Архитектура
Любой сервер может быть контроллером
Централизованный
контроль со стороны
ведущего узла Puppet
Централизованный
контроль со стороны
сервера Chef.
Скриптовый
язык
YAML
Специализированный
на базе Ruby
Ruby
Терминология скриптов
Playbook
(«сценарий»)
и roles («роли»)
Manifests и modules
Recipes («рецепты»)
и cookbooks («поваренные книги»)
Выполнение
тестов
Последовательный
порядок
Произвольный порядок
Последовательный
порядок
Рис. 11.6. Функциональность сервисов AWS OpsWorks
для управления Chef и Puppet
414
Глава 11. DevOps и фреймворк архитектуры решений
Безопасность стала приоритетом для любой организации, так что полную
автоматизацию безопасности можно считать насущной необходимостью. Организации переходят на жесткие реализации и мониторинг безопасности для
предотвращения человеческих ошибок, используя процесс DevOps, известный
под названием DevSecOps (сокращение от Development, Security, Operations,
то есть «разработка, безопасность, эксплуатация»).
DevSecOps
Современные разработчики уделяют безопасности гораздо больше внимания,
чем ранее. Зачастую безопасность оказывается единственным способом завое
вать доверие клиента. Суть DevSecOps заключается в автоматизации и масштабируемой реализации безопасности. Команда разработки постоянно вносит
изменения, а команда DevOps публикует их в продакшен-среде (изменения
часто ориентированы на клиента). DevSecOps обеспечивает безопасность приложения в общем процессе.
Внедрение DevSecOps не сводится к аудиту кода или артефактов CI/CD. Организации должны реализовать DevSecOps для обеспечения скорости и гибкости,
но не за счет проверок безопасности, которые замедляют процесс разработки
и развертывания. Эффективность автоматизации проявляется в повышении
гибкости выпуска новой функциональности одновременно с реализацией необходимых мер безопасности. Подход DevSecOps приводит к тому, что безопасность
становится неотъемлемой частью приложения; она не применяется «задним
числом». Практика DevOps направлена на ускорение жизненного цикла запуска
продукта, а 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 представлены стадии тестирования границ безопасности и обнаружения проблем безопасности, а также как можно более ранней проверки
соответствия политикам.
Кодинг
Сканирование секретов
Сборка
Тегирование артефактов
безопасности
Тестирование
Тестирование на соответствие
стандартам безопасности
Пайплайн
CI/CD
Безопасность
в CI/CD
Развертывание
Развертывание и регистрация
компонентов безопасности
Обеспечение
Мониторинг
Мониторинг стандартов
безопасности
Рис. 11.7. DevSecOps и CI/CD
416
Глава 11. DevOps и фреймворк архитектуры решений
y
y
y
y
y
Как показано на диаграмме, в каждой точке интеграции можно выявить различные проблемы.
y На этапе написания кода проводится сканирование всего кода для проверки,
что он не содержит никаких секретов или ключей доступа.
y На этапе сборки включаются все артефакты безопасности (например, ключи
шифрования и маркеры доступа), которые помечаются тегами для удобства
идентификации.
y На этапе тестирования проводится сканирование конфигурации для проверки соблюдения всех стандартов безопасности.
y На этапах развертывания и обеспечения проверяется регистрация всех
компонентов безопасности. Вычисление контрольной суммы позволяет
убедиться, что файлы сборки не были изменены. Метод контрольных сумм
используется для определения подлинности полученных файлов. Операционные системы предоставляют команду checksum для проверки файлов на
отсутствие изменений при передаче.
y На этапе мониторинга отслеживаются все стандарты безопасности, проводится непрерывный автоматизированный аудит и проверки.
В пайплайны DevSecOps можно интегрировать различные инструменты для
идентификации уязвимостей безопасности на разных стадиях, а также для сбора
и накопления информации об обнаруженных уязвимостях.
y
y
Практика AST (application security testing, проверка безопасности приложения),
включающая использование инструментов для автоматизации тестирования,
анализа уязвимостей, а также генерации соответствующих отчетов, является
критически важным компонентом разработки приложений. Процесс AST можно
разбить на четыре категории.
y Композиционный анализ программного продукта (SCA, software composite
analysis): SCA оценивает уровень безопасности программного продукта с открытым исходным кодом, соответствие лицензии и качество кода в кодовой
базе. SCA старается обнаружить уязвимости в зависимостях проекта. Популярные инструменты SCA — OWASP Dependency-Check, Synopsys Black
Duck, WhiteSource, Synk и GitLab.
y Статическое тестирование безопасности приложения (SAST, static
application security testing): SAST включает сканирование кода приложения
до компиляции. Оно предоставляет разработчикам немедленную обратную
связь в процессе написания кода, что позволяет исправлять ошибки до этапа
сборки. SAST относится к категории методов тестирования по принципу «белого ящика»: исходный код анализируется на предмет уязвимостей к атакам
на приложение. Ключевым преимуществом SAST является интеграция на
ранней стадии цикла DevOps, на этапе написания кода, так как эта практика
не требует ни функционирующего приложения, ни выполнения кода. Популярные инструменты SAST — SonarQube, PHPStan, Coverity, Synk, Appknox,
Klocwork, CodeScan и Checkmarx.
Реализация стратегии CD
417
y
y Динамическое тестирование безопасности приложения (DAST, dynamic
y
application security testing): DAST выявляет уязвимости безопасности, имитируя внешние атаки на приложение во время его выполнения. DAST обращается к приложению снаружи, проверяя внешние интерфейсы на наличие
уязвимостей. К числу инструментов DAST, также называемых средствами
тестирования безопасности по принципу «черного ящика» или сканерами
уязвимостей веб-приложения, относятся OWASP ZAP, Netsparker, Detectify
Deep Scan, StackHawk, Appknox, HCL AppScan, GitLab и Checkmarx.
y Интерактивное тестирование безопасности приложения (IAST, interactive
application security testing): IAST анализирует код на уязвимости безопасности во время активного тестирования или использования приложения;
таким образом вы получаете информацию о проблемах в реальном времени, не создавая задержек в пайплайне CI/CD. Инструменты IAST обычно
реализуются в средах QA наряду с автоматизированными функциональными тестами. Среди инструментов IAST заслуживают внимания GitLab,
Veracode, CxSAST, Burp Suite, Acunetix, Netsparker, InsightAppSec и HCL
AppScan.
Интеграция некоторых из упомянутых инструментов в пайплайн DevOps будет
рассмотрена в этой же главе позже, в разделе «Создание DevOps и DevSecOps».
Процесс DevSecOps CI/CD гарантирует, что код прошел проверку в соответствии
с корпоративной политикой безопасности. Это помогает избежать любых сбоев
инфраструктуры и приложения на этапе развертывания из-за несовместимых
настроек безопасности. DevSecOps поддерживает гибкость и обеспечивает безопасность в масштабе, не влияя на темп инноваций DevOps.
В следующем разделе рассматривается стратегия непрерывного развертывания
(CD) в пайплайне DevOps.
Реализация стратегии CD
y
y
y
y
y
CD обеспечивает бесшовную миграцию существующей версии приложения на
новую версию. Некоторые популярные методы реализации с применением CD:
y развертывание на месте (in-place deployment): обновляет приложение на
текущем сервере;
скользящее
(rolling) развертывание: постепенное развертывание новой
y
версии на существующем парке серверов;
y сине-зеленое (blue-green) развертывание: постепенная замена существующего сервера новым сервером;
y красно-черное (red-black) развертывание: мгновенное переключение на
новый сервер с существующего сервера;
y неизменяемое (immutable) развертывание: совместный запуск нового набора серверов.
Рассмотрим каждый из них более подробно.
418
Глава 11. DevOps и фреймворк архитектуры решений
Развертывание на месте
Развертывание на месте — метод запуска новой версии приложения на существую
щем парке серверов. Обновление выполняется за один раз и требует некоторого
периода неработоспособности. Этот способ не подразумевает практически никаких изменений инфраструктуры. Также не требуется обновлять существующие
записи DNS. Само развертывание выполняется относительно быстро. Если оно
завершается неудачей, то единственным способом восстановления является
повторное развертывание.
Простейший пример: вы заменяете существующую версию приложения (v1)
в инфраструктуре приложения новой версией (v2). Обновления обходятся
дешево и быстро развертываются.
Скользящее развертывание
При скользящем развертывании парк серверов делится на группы, чтобы
не выполнять обновление одновременно. В процессе развертывания старая
и новая версии работают в одном парке серверов, но в разных группах. Сколь
зящее развертывание помогает обеспечить нулевое время простоя. Если развертывание новой версии завершится неудачей, то это отразится только на
одной группе серверов, а риск будет минимальным, потому что оставшаяся
часть парка все еще будет нормально работать. При скользящем развертывании время простоя нулевое, но само развертывание длится чуть дольше, чем
развертывание на месте.
Скользящее развертывание не только сокращает время простоя, улучшая
пользовательский опыт, но и не требует лишних затрат на дополнительное выделение ресурсов. В отличие от сине-зеленого развертывания, которое требует
создания временного дубликата среды, скользящие развертывания обновляют
существующие ресурсы один за одним, избавляя от необходимости в лишней
инфраструктуре. Хотя время развертывания может немного увеличиться по
сравнению с развертыванием на месте, этот метод не приводит к лишним затратам из-за выделения дополнительных ресурсов, вследствие чего эта стратегия
эффективна для непрерывной поставки без последствий для бюджета.
Сине-зеленое развертывание
При сине-зеленом развертывании «синей» средой считается существующая рабочая среда, обслуживающая живой трафик. Параллельно создается «зеленая»
среда, в целом идентичная синей, но с новой версией кода. Когда наступает время
развертывания, рабочий трафик направляется из синей среды в зеленую. Если
в зеленой среде возникнут проблемы, рабочий трафик будет перенаправлен из
зеленой в исходную синюю среду. Переключение DNS и замена групп автомасштабирования — два самых популярных метода изменения маршрутизации
трафика при сине-зеленом развертывании.
Реализация стратегии CD
419
При использовании политики автомасштабирования можно постепенно заменять
существующие экземпляры экземплярами с новой версией приложения, когда
возникнет необходимость в его масштабировании. Этот вариант лучше подходит
для малых выпусков и небольших изменений в коде. Другой вариант — применение маршрутизации DNS — для сложной балансировки нагрузки между
разными версиями приложения.
Как показано на рис. 11.8, после создания рабочей среды, в которой размещается
новая версия приложения, можно использовать маршрут DNS для передачи
небольшой части трафика в новую среду.
70 %
30 %
Route 53
Маршрутизация DNS
Облако AWS
Балансировщик
нагрузки приложения
Балансировщик
нагрузки приложения
Парк серверов
Парк серверов
База данных
Рис. 11.8. Постепенное переключение DNS при сине-зеленом развертывании
Протестируйте зеленую среду на части рабочего трафика. Если в среде возникнут проблемы с функциональностью, вы немедленно узнаете об этом и переключите трафик обратно, пока они не успели оказать значительное влияние на
пользователей. Продолжайте постепенно переключать трафик, тестируя способность зеленой среды обрабатывать нагрузку. Организуйте мониторинг зеленой
среды для выявления проблем, чтобы трафик можно было вернуть, тем самым
420
Глава 11. DevOps и фреймворк архитектуры решений
ограничивая радиус поражения. Наконец, когда все метрики будут стабильны,
переведите в резерв синюю среду и освободите ресурсы.
Сине-зеленое развертывание помогает обеспечить нулевое время простоя и упрощает откат изменений. Вы можете настроить время развертывания в соответствии
с вашими потребностями. Однако нулевой простой затратен, так как требует
создания двух идентичных рабочих сред: активной (синей) и бездействующей
(зеленой). Необходимость дублирования среды означает более высокие затраты
из-за дополнительных ресурсов. Тем не менее эти затраты часто оправдываются
пользой, которую они приносят в плане снижения рисков и непрерывности
взаимодействия с пользователями.
Красно-черное развертывание
Прежде чем поднимать новую версию системы в красно-черном развертывании,
проведите канареечное тестирование (canary testing). Оно заменяет 1 % существующей рабочей системы новейшей версией приложения и организует мониторинг
новой версии на предмет ошибок. Система считается готовой к развертыванию,
если канареечный тест пройден. Новая версия системы существует параллельно
со старой и готова к переключению. Исходная емкость новой системы задается
вручную на основании количества работающих экземпляров — оно устанавливается в качестве желательной емкости новой группы автомасштабирования.
После того как новая система заработает, обе системы переходят в красное состояние, но трафик принимает только текущая версия.
Затем система переключается с существующей версии на новую при помощи
сервиса DNS. С этого момента старая версия считается черной; она все еще
работает, но не получает трафик. Если в новой версии обнаружатся проблемы,
возврат к старой версии будет сведен к простому перенаправлению сервера DNS
на балансировщик нагрузки старой версии.
Красно-черное развертывание несколько отличается от сине-зеленого. В красно-черной среде происходит мгновенное переключение DNS со старой версии
на новую (такая схема называется dark launch, или «тайный запуск»), тогда как
в сине-зеленом развертывании DNS постепенно наращивает трафик на новую
версию. Сине-зеленые и красно-черные развертывания могут объединяться,
чтобы обе версии программного продукта существовали одновременно. Используются два разных пути в коде, но только один из них активирован. Другой путь
активируется флагом включения функциональности. Такая схема развертывания может использоваться для бета-тестирования там, где включением новой
функциональности можно управлять явно.
Красно-черное развертывание, как и сине-зеленое, подразумевает запуск двух
одинаковых сред для обеспечения нулевого времени простоя и упрощения отката изменений. Затраты в основном связаны с необходимостью дублирования
ресурсов на этапе развертывания. Необходимо поддерживать «красную» среду
Выбор стратегии развертывания: лучшие практики
421
(текущая версия) и «черную» (новая версия). Обе среды должны быть полностью работоспособными, из-за чего требования к ресурсам в переходный период
фактически удваиваются — включая вычисления, хранилище и сетевые ресурсы.
Хотя этот подход значительно сокращает риски развертывания и обеспечивает
непрерывность взаимодействия с пользователями, дублирование среды приводит к увеличению затрат. Но так как дополнительные ресурсы необходимы
только на протяжении окна развертывания, эти затраты временные и их можно
рассматривать как вложения в стабильность и надежность.
Неизменяемое развертывание
Если приложение имеет неизвестные зависимости, то неизменяемое (immutable),
или «одноразовое» (disposable), обновление может быть более простым решением. Старую инфраструктуру приложения, которая неоднократно изменялась со
временем, становится все сложнее обновлять. Такой способ обновления более
типичен в неизменяемых инфраструктурах.
В новой версии развертывается новый набор экземпляров серверов, тогда как
старые экземпляры останавливаются. Для обновлений можно создать клонированную среду при помощи таких сервисов развертывания, как Chef, Puppet,
Ansible и Terraform, или использовать их в сочетании с конфигурацией автомасштабирования для управления обновлениями.
Кроме времени простоя, при проектировании стратегии развертывания необходимо учитывать затраты. Для расчета затрат определите количество экземпляров,
которое придется заменить, и частоту развертываний. Используйте оптимальный
подход к развертыванию с учетом требований к бюджету и времени простоя.
В этом разделе были рассмотрены разные стратегии CD, которые помогают
выпустить релиз эффективно и без проблем. В следующем разделе будут рассмотрены лучшие практики выбора типа развертывания.
Выбор стратегии развертывания:
лучшие практики
y
Выбор стратегии развертывания очень важен для успешных обновлений приложения и непрерывного взаимодействия с пользователями. Ниже перечислены
критерии для выбора наиболее подходящей стратегии.
y Развертывание на месте идеально для сценариев, когда особенно важна простота, а приложение относительно невелико или имеет ограниченную пользовательскую базу. Например, оно будет уместно при обновлении внутренних
инструментов компании силами небольшой команды. При развертывании
на месте приложение обновляется на текущем сервере, но важно отметить,
что этот вариант может привести к простоям. Эта стратегия не подходит для
крупномасштабных приложений или когда требуется высокая доступность.
422
Глава 11. DevOps и фреймворк архитектуры решений
y
y
y
y
Еще один типичный пример — обновление маломасштабного веб-сервиса
с низким пользовательским трафиком за ночь. Важно подготовить стратегию
отката изменений на случай, если обновление не сможет восстановить предыдущую версию, и быстро минимизировать нарушения работоспособности.
y Скользящее развертывание подходит для приложений, которые требуют
минимального простоя, но не нуждаются в дополнительных ресурсах. При
скользящем развертывании приложение обновляется постепенно на существующем парке серверов. Типичный пример — поэтапное развертывание
обновления на серверах интернет-магазина, когда лишь часть пользователей
может столкнуться с потенциальными проблемами. С другой стороны, этот
метод не подходит для приложений, которые не могут одновременно поддерживать несколько версий. Чтобы решать проблемы по мере их возникновения, важно проводить непрерывный мониторинг производительности
приложения в процессе развертывания.
y Сине-зеленое развертывание оптимально для приложений, которым критически важно нулевое время простоя. Финансовая компания может использовать эту стратегию для обновления своего клиентского приложения.
После того как зеленая среда будет тщательно протестирована и готова к использованию, трафик переключится с синей среды на зеленую. Метод требует
двойного объема ресурсов, но обеспечивает непрерывность взаимодействия
с пользователями и возможность быстрого отката. При этом очень важно,
чтобы механизмы балансировки нагрузки и переключения DNS работали
надежно и стабильно.
Красно-черное
развертывание похоже на сине-зеленое, но ориентировано на
y
ускоренное переключение на новую версию. Оно особенно эффективно для
быстрого выпуска новых версий и часто используется в контейнеризованных
средах. Например, сервис потоковой передачи видео может развернуть новую
версию своей платформы по этой стратегии, чтобы новая функциональность
немедленно стала доступной для всех пользователей. Хотя этот вариант
обеспечивает быстрый выпуск и немедленное переключение, очень важно
тщательно протестировать новую версию, потому что откат подразумевает
возврат к старой среде.
y Неизменяемое развертывание обеспечивает согласованность и надежность,
особенно в облачных средах. При каждом развертывании создаются новые
серверы, что гарантирует предсказуемость и стабильность состояния. Такой
подход может быть полезным в приложениях со сложными зависимостями,
так как позволяет избежать «дрейфа конфигураций» (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-тестирование
A/B-тестирование,
канареечное
тестирование
Рис. 11.9. Непрерывное тестирование в CI/CD
Этап сборки — первый тест интеграции между отдельными компонентами.
На этапе сборки также уместно протестировать, не нарушает ли код какуюлибо существующую функциональность, а кроме того, провести регрессионное
тестирование.
Промежуточная (стейдж) среда является зеркальной копией продакшен-среды.
На этой стадии выполняется сквозное тестирование системы (здесь достаточно
подробно тестируются UI, логика бэкенда и API). Тесты производительности
проверяют производительность приложения при конкретной рабочей нагрузке.
К тестам производительности относятся нагрузочные и стрессовые тесты.
На этой стадии также выполняется UAT-тестирование как часть подготовки
к развертыванию на продакшен. Тестирование соответствия выполняется для
проверки соответствия отраслевым нормативам.
Допустим, надо интегрировать непрерывное тестирование в пайплайн CI/
CD, чтобы проверить, как работает персонализация видео на стриминговой
интернет-платформе. Когда команда разработки сохраняет изменения в коде,
инструмент CI (например, Jenkins) автоматически инициирует процесс сборки и проводит серию автоматизированных тестов. В частности, выполняются
модульные тесты для проверки отдельных компонентов функции персонализации, интеграционные тесты для проверки совместимости с существующими
компонентами системы, а также UI-тесты, проверяющие взаимодействие с пользователями. Тесты производительности особенно важны в этом сценарии — они
проверяют, что новая функциональность не ухудшает качества стриминга. Если
во время проведения тестов возникают проблемы, пайплайн останавливается,
чтобы разработчики внесли необходимые исправления; это гарантирует, что
на следующую стадию пройдет только тщательно проверенный код. После
Реализация непрерывного тестирования в пайплайне CI/CD
425
прохождения автоматизированного тестирования функциональность переходит в стейдж-среду, которая имитирует условия продакшен, для дальнейшего
тестирования и проверки. Дополнительный уровень проверки гарантирует, что
функциональность будет хорошо работать в разных сценариях и вариантах поведения пользователя во время приемочного тестирования перед развертыванием.
A/B-тестирование
Зачастую при разработке программного продукта бывает неочевидно, какая
реализация той или иной функциональности окажется наиболее успешной. Ответу на этот вопрос посвящена целая научная дисциплина — человеко-машинное взаимодействие (HCI, human/computer interface). И хотя у UI-экспертов
имеются рекомендации, упрощающие проектирование удобных интерфейсов,
лучший вариант дизайна часто удается определить только одним способом:
представить его пользователям и посмотреть, смогут ли они с его помощью
решать свои задачи.
Такие стратегии, как A/B-тестирование или канареечное тестирование, проверяют новую рабочую версию приложения. При A/B-тестировании новая версия
приложения развертывается на небольшой части рабочих серверов, после чего
анализируется обратная связь от пользователей. Постепенно в зависимости от
того, насколько хорошо пользователи принимают новое приложение, развертывание расширяется вплоть до охвата всех рабочих серверов.
Как показано на рис. 11.10, в методологии A/B-тестирования две или более
версии функциональности предлагаются разным группам пользователей. Далее собираются подробные метрики использования каждой реализации, а UIинженеры изучают собранные данные, чтобы определить, какую реализацию
выбрать на будущее.
На диаграмме представлен сценарий A/B-тестирования, в которой разные версии
веб-приложения тестируются одновременно для оценки их производительности,
вовлеченности пользователя или других заранее определенных метрик. В этой
архитектуре процесс A/B-тестирования выглядит следующим образом.
1. Распределение трафика: балансировщик нагрузки приложения играет
важную роль в этой схеме: он направляет входящий трафик разным версиям веб-приложения. В рассматриваемом сценарии бˆольшая часть трафика
(90 %) направляется стабильной рабочей версии (V1.1), тогда как новые
тестируемые версии, V1.2 и V1.3, получают меньшие доли трафика (7 и 3 %
соответственно).
2. Парк веб-серверов: каждая версия приложения работает на отдельной группе веб-серверов или экземпляров. Это гарантирует, что изменения в одной
версии не затронут другие версии. Такая изоляция важна для получения
точных результатов тестирования. Версия, получающая бˆольшую часть
трафика, служит контрольной группой, а остальные версии с изменениями
или новой функциональностью — тестовыми группами.
426
Глава 11. DevOps и фреймворк архитектуры решений
3. База данных: все версии приложения взаимодействуют с одной базой данных
на бэкенде. Это стандартная практика для A/B-тестов, где разные варианты
пользовательского интерфейса используют общие данные. Однако при этом
необходимо проверить совместимость схем базы данных между версиями
и единообразие операций с данными, чтобы предотвратить ошибки или несогласованность при работе с данными.
В процессе A/B-тестирования необходимо непрерывно отслеживать метрики
производительности, чтобы оценить, как каждая версия приложения работает
в реальных условиях. К числу таких метрик относятся время отклика, частота
ошибок, степень использования ресурсов и т. д. После сбора значительного
объема данных результаты анализируются и делается вывод, какая версия
приложения лучше всего соответствует критериям тестирования. На осно
вании результатов A/B-тестов принимается решение о том, стоит ли полностью
развернуть новую версию, продолжать вносить изменения или отменить их.
Балансировщик нагрузки приложения
90 %
Парк веб-серверов
7%
3%
V1.1
V1.1
V1.2
V1.3
V1.1
V1.1
V1.2
V1.3
База данных
Рис. 11.10. Проверка новой функциональности
с помощью A/B-тестирования
Инструменты DevOps для CI/CD
427
Инструменты DevOps для CI/CD
Для создания пайплайна CI/CD разработчику потребуются инструменты. К их
числу относится редактор кода, репозиторий исходного кода, сервер сборки,
система развертывания и средства оркестрации всего пайплайна CI. Рассмотрим
некоторые популярные средства разработчика для DevOps — как для облачных,
так и для локальных сред.
Редактор кода
В практике DevOps для автоматизации среды часто приходится писать скрипты.
Для этого можно воспользоваться редактором Ace или облачной интегрированной средой разработки (IDE) AWS Cloud9. В Ace есть подсветка синтаксиса
и другая удобная для разработчиков функциональность. Cloud9 интегрируется
с платформой AWS, что позволяет разработчикам легко создавать бессерверные приложения и работать с сервисами AWS. Также Cloud9 поддерживает
совместное программирование и основные средства для работы с популярными
языками программирования.
Можно использовать редактор кода на локальном компьютере или же установить
его на локальном сервере, подключенном к средам приложения (разработки,
тестирования, продакшен) для взаимодействия с ними. В среде сохраняются
файлы проекта и запускаются средства для разработки приложений. Можно
сохранять файлы локально на экземпляре или сервере или же клонировать
удаленный репозиторий кода в свою среду. AWS Cloud9 IDE — это облачная
IDE, которая предоставляется как управляемый сервис.
Ace позволяет быстро и легко писать код. Это редактор кода на базе вебтехнологий, но по производительности он не уступает таким популярным
десктопным редакторам кода, как Eclipse, Vim, Visual Studio Code (VS Code)
и т. д. Он поддерживает различные стандартные средства IDE, например динамическую подсветку синтаксиса и выделение парных скобок, автоматическую
расстановка отступов и автозавершение, переключение между вкладками,
интеграцию с системами контроля версий и множественное выделение. Ace
работает с большими файлами, содержащими сотни тысяч строк, без задержки при вводе. Он обладает встроенной поддержкой всех популярных языков
программирования и средств отладки; кроме того, он позволяет устанавливать
свои инструменты. Среди десктопных 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 EC2 (Elastic Compute
Cloud) и автоматически масштабировать его в соответствии
с нагрузкой.
В случае перегрузки контроллер
Jenkins поручает сборку экземпляру агентского узла. Когда
нагрузка снижается, контроллер
автоматически завершает экземпляры агентов.
Контроллер Jenkins
Агент Jenkins
Агент Jenkins
Агент Jenkins
Рис. 11.12. Автомасштабирование
CI-серверов Jenkins
Тем не менее поддерживать безопасность и устанавливать патчи на сервере придется самостоятельно. Для платформенных облачных решений и управляемых
сервисов можно воспользоваться управляемыми сервисами сборки кода (такими, как AWS CodeBuild); это избавит от необходимости в администрировании
сервера и значительно сократит затраты с моделью оплаты по фактическому
использованию — сервис масштабируется по мере необходимости. Команда
получает возможность сосредоточиться на отправке кода, а сервис сам создает
все артефакты.
Сервер CI помогает собирать корректную версию кода из репозитория исходного кода, обеспечивая совместную работу членов команды разработчиков, тогда
как развертывание кода позволяет команде подготовить код к тестированию
и релизу для конечных пользователей. В следующем разделе развертывание
кода рассматривается более подробно.
430
Глава 11. DevOps и фреймворк архитектуры решений
Развертывание кода
y
y
y
y
По завершении сборки можно развернуть сервер Jenkins или выбрать AWS
CodeDeploy в качестве облачно-ориентированного управляемого сервиса. Для
создания скрипта развертывания можно воспользоваться популярными инструментами (например, Chef или Puppet). Поддерживаются следующие варианты
конфигурации развертывания.
y OneAtATime: в любой момент времени только один экземпляр в группе развертывания создает новое развертывание. Представим, что развертывание
для заданного экземпляра завершилось неудачей. В таком случае скрипт
остановит его и вернет сообщение об ошибке с указанием количества успешных и ошибочных установок.
y HalfAtATime: новое развертывание создается половиной экземпляров в группе
развертывания. Развертывание проходит успешно, если половина экземпляров успешно устанавливает изменение. Вариант HalfAtATime хорошо подходит
для рабочих/тестовых сред, в которых половина экземпляров обновляется
новой версией, а другая половина остается в рабочем состоянии и доступна
со старой версией.
y AllAtOnce: каждый экземпляр устанавливает последнюю доступную версию,
когда в следующий раз опрашивает сервис развертывания. Этот вариант
лучше использовать для развертываний в средах разработки и тестирования,
так как он может привести к установке нефункциональной версии на каждом
экземпляре в группе развертывания.
y Custom: эта команда может использоваться для создания нестандартной конфигурации развертывания с указанием фиксированного количества работоспособных хостов, которые должны существовать в группе развертывания
в любой конкретный момент. Этот вариант представляет собой более гибкую
реализацию варианта OneAtATime. Он допускает возможность того, что развертывание завершится неудачей на одном или двух экземплярах, которые
были повреждены или неправильно сконфигурированы.
На рис. 11.13 представлены события жизненного цикла развертывания.
Агент развертывания проходит через серию этапов, они называются событиями
жизненного цикла. Рассмотрим их более подробно.
1. ApplicationStop: чтобы запустить развертывание, первым шагом должна
стать остановка сервера приложения, прерывающая обработку трафика на
время копирования файлов. Примеры серверов приложений — Tomcat, JBoss
и WebSphere.
2. DownloadBundle: после остановки сервера приложения агент развертывания
начинает загружать заранее созданный пакет развертывания из хранилища
артефактов — такого, как JFrog Artifactory. Там хранится двоичный файл
приложения, который можно развернуть и протестировать до запуска новой
версии.
Инструменты DevOps для CI/CD
431
3. BeforeInstall: агент развертывания инициирует различные действия, предшествующие установке, — например, создание резервной копии текущей
версии и необходимое обновление конфигурации с помощью скрипта.
4. Install: на этом шаге агенты развертывания начинают установку — например,
запускают скрипт Maven или Ant для установки приложения Java.
5. AfterInstall: агент развертывания инициирует этот шаг после завершения
установки приложения. Он может включать обновление конфигурации
после установки (например, настроек локальной памяти и параметров
журнала).
6. ApplicationStart: на этом шаге агент запускает приложение и оповещает
группу эксплуатации об успехе или неудаче.
7. ValidateService: последний этап — проверка (валидация). В него входит
автоматизированная проверка работоспособности и интеграционные тесты
для проверки, правильно ли установлена новая версия приложения. Агент
также отправляет уведомление в случае успешного тестирования.
Агент
развертывания
(начало)
ApplicationStop
DownloadBundle
Конец
ValidateService
ApplicationStart
BeforeInstall
AfterInstall
Install
Рис. 11.13. События жизненного цикла развертывания
Мы рассмотрели разные стратегии и этапы развертывания кода как независимые
компоненты. Однако для создания автоматизированного пайплайна CI/CD все
фазы DevOps необходимо объединить. Более подробное знакомство с пайплайном кода поможет создавать сквозные пайплайны CI/CD.
432
Глава 11. DevOps и фреймворк архитектуры решений
Пайплайн кода
Пайплайн кода объединяет все компоненты для реализации CD. Весь процесс
выпуска полностью автоматизируется в CD, включая сборку и развертывание рабочей версии. С течением времени, поэкспериментировав, вы сможете настроить
надежный пайплайн CI/CD. Путь к запуску рабочей версии автоматизирован,
что обеспечивает быстрое развертывание функциональности и немедленную обратную связь от пользователей. Для координации всего пайплайна кода можно
воспользоваться облачно-ориентированными управляемыми сервисами (такими,
как AWS CodePipeline) или сервером Jenkins.
y
y
y
y
y
y
Пайплайн кода позволяет добавлять новые действия на разные стадии пайплайна CI/CD. Каждое действие может быть связано с поставщиком, который
это действие выполняет. Вот основные категории действий в пайплайне кода
и примеры поставщиков.
y Исходный код: код приложения должен храниться в центральном репозитории с контролем версий — репозитории исходного кода. Примеры популярных
репозиториев кода: AWS CodeCommit, Bitbucket, GitHub, CVS (Concurrent
Versions System), Subversion (SVN) и др.
y Сборка: система сборки извлекает код из репозитория исходного кода и создает двоичный пакет приложения. Примеры популярных систем сборки: AWS
CodeBuild, Jenkins, Solano CI и др. После того как сборка будет завершена,
двоичные файлы можно сохранить в хранилище артефактов — например,
JFrog.
y Развертывание: инструменты развертывания упрощают задачу развертывания двоичных файлов приложения на сервере. Примеры популярных инструментов: AWS Elastic Beanstalk, AWS CodeDeploy, Chef, Puppet, Jenkins и др.
y Тестирование: автоматизированные инструменты тестирования помогают
завершить и выполнить проверку после развертывания. Примеры популярных инструментов тестирования: Jenkins, BlazeMeter, Ghost Inspector и т. д.
Вспомогательные
операции: для выполнения таких операций, например
y
резервного копирования или уведомлений, можно воспользоваться скриптом на основе событий. Для выполнения специальных операций может
использоваться любой скриптовый язык: командной оболочки, PowerShell
или Python.
y Подтверждение: исключительно важный этап CD. Можно запросить ручное
подтверждение через автоматизированную отправку сообщения электронной
почты либо автоматизировать процесс подтверждения на уровне инструментов.
В этом разделе вы узнали о различных инструментах DevOps для управления
жизненным циклом разработки продукта (SDLC, sotware development life
cycle) — редакторе кода, репозитории, инструментах сборки, тестирования и развертывания. Другие инструменты, которые часто интегрируются в пайплайны
Реализация лучших практик DevOps
433
DevOps, — непрерывное ведение журнала, непрерывный мониторинг и эксплуатация, о которых вы узнали в главе 9 «Операционное совершенство». Мы также
рассмотрели методы DevOps, применимые на каждом этапе SDLC. В следующем
разделе речь пойдет о лучших практиках и антипаттернах.
Реализация лучших практик DevOps
Допустим, что при построении пайплайна CI/CD необходимо создать проект
и добавить в него участников. Дашборд проекта наглядно представляет прохо
ждение кода по пайплайну развертывания, ведет мониторинг сборки, инициирует
уведомления и отслеживает активности приложения. На рис. 11.14 представлен
хорошо определенный пайплайн DevOps.
Администратор
DevOps
Создание проекта
и добавление
пользователя
Разработчик
фиксирует
изменения
Изменения
проходят сборку
и тестирование
Код
развертывается
на продакшен
Мониторинг
приложения
Авторизованный
пользователь
Внесение
изменений
Новые идеи, запросы и сообщения
об ошибках
Клиент
Рис. 11.14. Образцовый поток операций CI/CD
y
y
y
y
При проектировании пайплайна необходимо учитывать следующее.
y Количество стадий: основные стадии — развертывание, интеграция, системная стадия, одобрение пользователем и продакшен. В некоторых организациях
также включаются стадии разработки, альфа, бета и релиза.
y Типы тестов на каждой стадии: на каждой стадии могут выполняться тесты
разных типов: модульные, интеграционные, системные, UAT, тесты на общую
работоспособность, нагрузочные тесты и тесты A/B на продакшен.
y Последовательность выполнения тестов: тесты могут выполняться параллельно или последовательно.
Мониторинг
и отчетность: отслеживайте дефекты и сбои в системе и отy
правляйте уведомление о возникающих проблемах.
434
Глава 11. DevOps и фреймворк архитектуры решений
y
y Предоставление инфраструктуры: методы предоставления инфраструктуры
для каждой стадии.
y
y Откат: определите стратегию отката для возврата к предыдущей версии
в случае необходимости.
Если ручное вмешательство происходит там, где его можно избежать, это
замедляет процесс разработки. Таким образом, автоматизация процесса с использованием CD ускорит его.
Еще один распространенный антипаттерн — хранение данных конфигурации
сборки внутри кода, а также ситуация, когда разработчики используют разные
инструменты сборки, что приводит к рассогласованию сборок. Чтобы понять,
почему конкретная сборка работает в одной среде, но не работает в других, потребуется много времени и усилий. Для решения этой проблемы лучше хранить
конфигурации сборки за пределами кода.
Предоставление доступа к этим конфигурациям для инструментов, обеспечивающих согласованность сборок, повышает качество автоматизации и значительно ускоряет масштабирование процесса. Отказ от использования процесса
CD может привести к ночным авральным попыткам заставить сборку работать.
Проектируйте CD для быстрого провала (fail fast); это сократит риск неприятных
сюрпризов, возникающих в последний момент.
y
y
y
y
Внешнее хранение конфигураций, относящихся к конкретным средам, способствует поддержанию согласованности и масштабируемости между сборками.
Перечислим некоторые инструменты и сервисы, упрощающие эту абстракцию.
y Хранилище параметров AWS Systems Manager Parameter Store: предоставляет безопасное иерархическое хранилище для управления данными
конфигурации и секретами. Здесь можно хранить такие данные, как пароли, строки подключения к базам данных и коды лицензий как значения
параметров.
y ConfigMaps и Secrets в Kubernetes: объекты Kubernetes, позволяющие отделить артефакты конфигурации от содержимого образов, чтобы контейнеризованные приложения оставались портируемыми.
y Docker Swarm Secrets: используется для управления конфиденциальными
данными в контейнерах Docker; предоставляет возможность безопасной
передачи и хранения секретов в кластере Swarm.
y HashiCorp Consul: сетевое решение для автоматизации сетевых конфигураций с использованием распределенных хранилищ пар «ключ — значение».
При помощи этих инструментов можно управлять конфигурациями и секретами
за пределами кода приложения и шаблонов, что упрощает управление и ротацию
без повторного развертывания или изменения приложения.
Мониторинг ключевых показателей эффективности (KPI, Key Performance
Indicators) играет важнейшую роль для эффективной оценки влияния CI/CD
в структуре DevOps. Важнейшие KPI в области CI/CD:
Создание процессов DevOps и DevSecOps на облачных платформах
435
y
y частота развертывания — сигнализирует о том, насколько часто обновления
достигают продакшен, и отражает гибкость процесса выпуска;
y
y общее время внесения изменений, то есть продолжительность периода от
y
y
y
коммита до живого развертывания; чем короче интервалы, тем эффективнее
цикл разработки;
y частота сбоев при изменениях — определяет долю развертываний, приводящих к сбоям; чем она ниже, тем выше стабильность развертывания;
y среднее время восстановления (MTTR, mean time to recovery) оценивает среднюю продолжительность восстановления при сбоях; более быстрое восстановление свидетельствует об эффективности управления инцидентами в команде;
y частота прохождения автоматизированных тестов оценивает надежность кода
через частоту успешности автоматизированных тестов в каждом цикле CI/CD.
Для применения лучших практик на каждом шаге разработки приложения
можно использовать принципы методологии Twelve-Factor App (12-факторное
приложение, https://12factor.net/), принятой для сквозной разработки и поставки
веб-приложений. Методология применима на любых платформах программирования независимо от языка программирования.
В наши дни многие продукты имеют формат веб-приложений и используют
облачные платформы. Посмотрим, как создать сквозной процесс DevOps
и автоматизировать безопасность в облаке.
Создание процессов DevOps и DevSecOps
на облачных платформах
Как вы узнали из предыдущих разделов, построение CI/CD-пайплайна требует
множества инструментов, а добавление автоматизации безопасности только
повышает сложность. Интеграция различных инструментов и консолидация
результатов оценки уязвимости «с нуля» может быть сложной задачей. Облачные
провайдеры (например, AWS) предлагают необходимую гибкость для создания
DevSecOps-пайплайнов. Это включает простую интеграцию как облачно-ориентированных, так и сторонних инструментов, а также возможность эффективного
агрегирования результатов анализа безопасности.
y
y
Архитектура DevSecOps-пайплайна использует практики CI/CD, включая
инструменты SCA, SAST и DAST.
y Инструменты SCA (композитный анализ программного продукта) анализируют компоненты с открытым исходным кодом для выявления известных
уязвимостей, проблем лицензирования и устаревших библиотек. Они могут
автоматизировать процесс проверки обновлений и патчей безопасности,
упрощая управление зависимостями приложения.
y Инструменты SAST (cтатическое тестирование безопасности приложения)
предназначены для анализа исходного кода или скомпилированных версий
436
Глава 11. DevOps и фреймворк архитектуры решений
y
кода, чтобы выявлять уязвимости безопасности. Они могут обнаруживать
такие проблемы, как ошибки проверки ввода, небезопасные зависимости
и потенциальные бэкдоры без выполнения кода.
y Инструменты DAST (динамическое тестирование безопасности приложения)
оценивают работающее приложение на предмет уязвимостей. В отличие от
инструментов SAST, анализирующих статический код, инструменты DAST
взаимодействуют с приложением снаружи, выполняя тестирование по принципу «черного ящика» для выявления таких проблем, как SQL-инъекции,
межсайтовый скриптинг и проблемы с аутентификацией.
Интеграция этих инструментов в пайплайн CI/CD позволяет организовать непрерывное и автоматизированное тестирование безопасности. Таким образом
команды быстрее могут обнаруживать и решать проблемы безопасности, что повышает общую безопасность приложения. На рис. 11.15 наглядно представлены
концепции автоматизации безопасности в пайплайне.
Анализ
сканирования
Lambda
AWS Code Amazon S3
Artifacts
SCA
AWS
CloudTrailArtifacts
SAST
Security Hub
AWS Config
IAST
DAST
Стейдж
Развертывание
Сборка
Тестирование
Тестирование
Развертывание (DAST, IAST) Развертывание Развер(SCA, SAST)
CodePipeline
тывание
Коммит
Команда
разработки
Git
CodeCommit
CodeBuild
CodeDeploy
Ручное
подтверждение
CodeBuild
Elastic Container Service
Продакшен
CodeDeploy
Elastic Container Service
Email
Роль AWS IAM
Команда DevOps/ Simple Notification
разработки
Service
Событие CloudWatch
Журналы
CloudWatch
Хранилище
параметров
Рис. 11.15. Архитектура пайплайна CI/CD процесса DevSecOps
на облачной платформе AWS
Создание процессов DevOps и DevSecOps на облачных платформах
437
Как показано на диаграмме, пайплайн CI/CD срабатывает при отправке коммита
на GitHub. Событие для запуска 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 может быть достигнута только
повсеместным применением автоматизации. Вы узнали об IaC и управлении
конфигурацией в контексте автоматизации. Также были рассмотрены инструменты автоматизации (например, Chef, Puppet и Ansible) для управления
конфигурацией.
Так как приоритетом разработки является безопасность, мы рассмотрели практику DevSecOps. По сути она представляет собой DevOps с учетом безопасности.
Непрерывное развертывание (CD) является одним из важнейших условий
DevOps. Мы поговорили о существующих стратегиях развертывания: сколь
зящем, сине-зеленом и красно-черном. Еще одним условием обеспечения качества продукта является тестирование. Вы узнали о концепции непрерывного
тестирования в DevOps и о том, как A/B-тестирование поможет улучшить
продукт за счет получения прямой обратной связи от клиентов.
Мы обсудили стадии CI/CD-пайплайна, инструменты и сервисы, которые
используются на каждой стадии, и лучшие практики создания надежного CI/
CD-пайплайна. Мы также разобрали, как работают отдельные сервисы, и обсудили возможности интеграции сервисов для построения сложного решения.
Итак, вы изучили параметры архитектуры решений. Поскольку каждая организация работает с большими объемами данных, она тратит много усилий на их
анализ. В следующей главе вы узнаете о сборе, обработке и потреблении данных
для их более глубокого понимания.
ГЛАВА 12
ИНЖЕНЕРИЯ ДАННЫХ
ДЛЯ АРХИТЕКТУР РЕШЕНИЙ
В предыдущей главе вы узнали о процессе DevOps, который автоматизирует
пайплайн развертывания приложений и продвигает культуру совместной работы среди команд разработки, эксплуатации и безопасности. В этой главе вы
познакомитесь с инженерией данных, в том числе с инструментами и методами, используемыми для сбора данных из различных частей приложения для
получения аналитической информации, которая может направлять развитие
бизнеса.
В интернете и в цифровую эпоху повсюду стремительно генерируются огромные
объемы данных. Быстро извлекать из них аналитическую информацию — непростая задача. Чтобы получать полезные для бизнеса результаты, необходимо
постоянно заниматься поглощением, сохранением и обработкой этих данных.
Слияние облачных, мобильных и социальных технологий способствует непрерывным достижениям во многих областях — таких, как геномика и естественные
науки. Глубокий анализ данных для их лучшего понимания имеет огромную
ценность. Современные стриминговые системы должны непрерывно генерировать результаты обработки данных, поступающих с высокой частотой, при
низкой задержке.
Концепция больших данных (Big Data) не сводится к их простому сбору и анализу. Действительная ценность, которую организации могут извлечь из своих
данных, может использоваться для получения аналитической информации
и создания конкурентных преимуществ. Не все решения для больших данных
подразумевают визуализацию. Многие — например, машинное обучение (МО)
и другая прогнозная аналитика — поставляют свои выводы программно другим
инструментам или приложениям, извлекая информацию и отвечая заданным
образом.
Как это часто бывает, высокая скорость получения результатов обходится дорого, и Big Data не исключение. Иногда ответы не нужны немедленно, а задержка
и пропускная способность решения достаточно гибкие, так что на завершение
440
Глава 12. Инженерия данных для архитектур решений
обработки могут понадобиться часы. В других ситуациях (например, в рамках
прогнозной аналитики) ответы нужны сразу же после получения данных.
y
y
y
y
y
y
В этой главе рассматриваются следующие темы, относящиеся к обработке
и управлению потребностями в области больших данных.
y Что представляет собой архитектура Big Data?
y Проектирование пайплайнов обработки Big Data.
y Поглощение данных, хранение, обработка и аналитика.
y Визуализация данных.
y Проектирование архитектур Big Data.
y Лучшие практики архитектуры Big Data.
К концу этой главы вы узнаете, как проектировать архитектуру больших данных
и аналитики. Вы изучите основные этапы пайплайна больших данных, включая поглощение данных, хранение, обработку, визуализацию и архитектурные
паттерны.
Что представляет собой архитектура Big Data?
Огромный объем собранных данных может создавать проблемы. С накоплением
все большего объема данных управлять и перемещать их вместе с нижележащей
инфраструктурой становится все сложнее. Рост популярности облака упростил
возможность перемещения приложений на облачные платформы.
y
y
y
y
Поступление данных из разных источников приводит к росту объемов, скорости
и разнообразия данных. Ниже приведены лишь несколько примеров распространенных источников данных, генерируемых компьютером.
y Журналы серверов приложений: журналы приложений и игр.
y Журналы сведений о посещениях: активность на сайтах и история просмотров.
y Данные от датчиков: погоды, воды, энергии ветра, интеллектуальных сетей.
y Графика и видео: камеры уличного движения и безопасности.
Компьютеры могут генерировать разные виды данных, от полуструктурированных журналов до неструктурированных двоичных данных. Сгенерированные
данные могут использоваться для поиска по шаблону или нахождения корреляций в данных, на основе чего генерируются рекомендации для социальных
сетей и сетевых игр. Данные, сгенерированные компьютером, — блоги, отзывы,
электронная почта, графика, восприятие бренда — также могут использоваться
для отслеживания поведения приложений или сервисов.
К данным, генерируемым человеком, относятся, например, результаты поиска
по электронной почте, запросы на естественном языке, анализ тональности
и рекомендации продуктов. Анализ социальных графов может создавать рекомендации продуктов на основании вашего круга друзей, профессий, которые
Что представляет собой архитектура Big Data?
441
вы считаете интересными, или даже напоминания о днях рождения, юбилеях
и т. д. в вашем кругу друзей.
y
y
y
y
Назовем типичные препятствия, которые мешают командам по аналитике данных
приносить максимальную пользу своим организациям.
y Ограниченная информация о пользовательском опыте и эксплуатации:
чтобы создавать новые варианты взаимодействия с пользователями, организации должны лучше понимать свой бизнес. Сложный и затратный сбор
данных, системы обработки и дополнительные расходы на масштабирование
заставляют организации ограничивать типы и объем собираемых и анализируемых данных.
y Необходимость ускоренного принятия решений. Это комплексная проблема,
включающая две составляющие:
традиционные системы данных перегружены, из-за чего завершение рабочих нагрузок требует больше времени;
на принятие многих решений должны уходить только секунды или
минуты, из-за чего системы должны собирать и обрабатывать данные
в реальном времени.
y Возможность инноваций на базе МО: организации добавляют и расширяют
команды data science для оптимизации и развития бизнеса. Командам требуется расширенный доступ к данным из выбранных ими инструментов без
типичных преград и процессов, которые замедляют их работу.
y Технический персонал и затраты на масштабирование самоуправляемых
инфраструктур: клиентам, которые управляют инфраструктурой локально,
необходима помощь с быстрым масштабированием под потребности бизнеса.
Управление инфраструктурой, высокая доступность, масштабирование и мониторинг операций — все это занимает время, особенно в масштабе.
В архитектуре 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
y
y
y
y
y
Big Data обычно не обеспечивают оптимального баланса пропускной способности и затрат. При проектировании архитектуры данных следует использовать
принципы FLAIR:
y F — поисковая доступность (Findability): возможность простого обнаружения доступных данных и обращения к их метаданным, включающим такую
информацию, как владелец и классификация данных, наряду с другими критически важными атрибутами, необходимыми для рационального управления
данными и комплаенса;
y L — происхождение (Lineage): возможность отслеживания источника данных, их перемещений и истории, а также понимания и визуализации потоков
данных от источников к точкам потребления;
y A — доступность (Accessibility): возможность запрашивать и получать
сертификаты безопасности, открывающие доступ к конкретному массиву
данных. Также подразумевает необходимость в сетевой инфраструктуре,
поддерживающей эффективный доступ к данным;
y I — совместимость (Interoperability): хранение данных в форматах, к которым
могут обращаться и которые могут использовать большинство (если не все)
внутренних систем обработки;
y R — повторное использование (Reusability): данные должны быть документированы с заданной схемой, а источник данных должен быть четко обозначен.
Этот принцип часто включает принципы управления основными данными
(MDM, Master Data Management), ориентированного на управление критически важными данными из разных предметных областей; таким образом
формируется единая отправная точка для работы с данными.
Архитекторы больших данных рекомендуют разделять в пайплайне фазы поглощения, хранения, обработки и получения аналитики. Разделение хранения
и обработки на несколько стадий обладает рядом преимуществ, включая повышение отказоустойчивости. Например, если что-то пойдет не так на втором круге
обработки и оборудование, выделенное для этой задачи, выйдет из строя, вам
не придется возвращаться к началу пайплайна; система сможет продолжить со
второй стадии хранения. Отделение хранения от уровней обработки позволяет
выполнять операции чтения и записи из нескольких хранилищ данных.
На рис. 12.2 изображены различные инструменты и процессы пайплайна архитектуры Big Data.
y
y
y
y
Факторы, которые необходимо учитывать при выборе инструментов для архитектур больших данных:
y структура данных;
y максимальная допустимая задержка;
y минимальная допустимая пропускная способность;
y типичные шаблоны обращений конечных пользователей системы.
444
Глава 12. Инженерия данных для архитектур решений
Сбор
Хранение
Транзакционный API
и режим по требованию
Импорт данных
Веб-серверы /
серверы приложений
Очередь сообщений
Почти в реальном
времени
Обработка
и анализ
Near Real-Time
Визуализация
Бизнес-аналитика
и визуализация данных
Экосистема Hadoop
Производительность
Хранилище данных
Elasticsearch Analytics
Интернет вещей
Машинное обучение
Поиск
Аналитика Elasticsearch
NoSQL
Near Real-Time
Встраиваемые
дашборды
Обработка и перемещение
данных
РСУБД
Аналитика для
приложений Java
Хранилище объектов
Ситуативная аналитика
Рис. 12.2. Инструменты и процессы архитектуры Big Data
Структура данных влияет как на инструменты, используемые для их обработки,
так и на место их хранения. Упорядочение данных и размер каждого объекта,
который вы сохраняете и читаете, также играют важную роль при принятии
решения. Соотношение задержки / пропускной способности и затрат определяет время ответа.
Шаблоны пользовательских обращений — еще один важный компонент. Одни
задания требуют регулярного соединения многих связанных таблиц, другие —
ежедневного или менее частого сохранения данных. Третьи задания требуют
сравнения данных из широкого диапазона источников, четвертые извлекают
данные из одной неструктурированной таблицы. Если вы знаете, как конечные
пользователи будут чаще всего работать с данными, это поможет вам определить
ширину и глубину архитектуры Big Data. В следующем разделе все процессы
и инструменты, задействованные в архитектуре больших данных, рассматриваются более подробно.
Поглощение данных, сохранение, обработка
и аналитика
Чтобы преобразовать необработанные данные в информацию, которая может
стать основанием для принятия решений и стратегического планирования, их
Поглощение данных, сохранение, обработка и аналитика
445
необходимо провести через несколько этапов. Все начинается с поглощения
данных (data ingestion) — сбора данных из разных источников. Это могут быть
данные, сгенерированные пользователем, журналы, потоковые данные реального
времени и т. д. После того как данные будут собраны, их необходимо сохранить
в хранилище данных: базе данных, озере данных, облачном хранилище — в зависимости от типа данных и их предполагаемого использования.
После сохранения начинается этап обработки данных и аналитики, в том числе
сортировки, агрегирования или преобразования данных в удобную форму, позволяющую проводить аналитику обработанных данных для получения значимой информации. Аналитика представлена в широком диапазоне, от простых
запросов и отчетов до сложных алгоритмов МО и прогнозного моделирования.
Рассмотрим названные этапы более подробно.
Поглощение данных
Поглощение данных представляет собой сбор данных для их перемещения
и хранения. Существует много источников, из которых данные могут поступать
в систему. Как правило, это базы данных, потоки данных, журналы и файлы.
Самый популярный из этих источников — базы данных. Обычно это транзакционные системы, являющиеся основным хранилищем данных приложений. Они
делятся на реляционные и нереляционные, и существует множество способов
извлечь из них данные.
Потоки данных представляют собой неограниченные последовательности данных с привязкой по времени (например, данных взаимодействий с веб-сайтов
или устройств интернета вещей, IoT), обычно публикуемые при помощи API,
которые вы предоставляете. Приложения, сервисы и операционные системы
генерируют журналы. Как показано на рис. 12.3, для выбора способа поглощения, идеально подходящего для ваших целей, следует учитывать тип данных,
собираемых средой, и способ их сбора.
Как показано на диаграмме, транзакционное хранилище данных должно быть
способно оперативно сохранять и загружать данные. Конечным пользователям
нужен быстрый и несложный доступ к данным, поэтому серверы приложений
и веб-серверы идеальны для целей поглощения. По тем же причинам базы данных NoSQL и реляционная система управления базой данных (РСУБД) обычно
лучше всего подходят для этого процесса.
Данные, передаваемые в отдельных файлах, обычно поглощаются с подключенных устройств. Большой объем файловых данных не требует быстрого хранения
и выборки по сравнению с транзакционными данными. Передача файловых
данных часто осуществляется в одном направлении: данные производятся несколькими ресурсами и поглощаются в одном объекте или файловом хранилище
для дальнейшего использования.
446
Глава 12. Инженерия данных для архитектур решений
Транзакционные:
база данных для
чтения/записи
Файлы
Сервер приложения
База данных
Веб-сервер
Устройства
Датчики мобильных
IoT
приложений
Облачное хранилище
Fluentd
Поток данных
Sqoop
Потоковое
хранилище
Storm
Рис. 12.3. Типы поглощения данных
Для поглощения потоковых данных — например, журналов посещений — требуются соответствующие решения (такие, как Apache Kafka или Fluentd). Apache
Kafka — популярный вариант, предоставляющий надежную функциональность
«публикация — подписка», способную эффективно обрабатывать огромные
объемы данных. Fluentd — еще один инструмент, который можно использовать
для поглощения данных, — известен прежде всего своей функциональностью
агрегирования журналов.
Изначально журналы хранятся в потоковом хранилище (например, Kafka), что
позволяет использовать их для обработки и анализа в реальном времени. Для
долгосрочного хранения журналов лучше использовать низкозатратные решения — например, хранилища объектов.
Потоковое хранилище отделяет систему сбора (производителей) от системы
обработки (потребителей). Оно формирует долгосрочный буфер для входных
данных. Данные могут обрабатываться, и частоту их подачи можно настроить
в зависимости от потребностей. Рассмотрим некоторые популярные методы
поглощения данных.
Выбор технологии поглощения данных
Рассмотрим некоторые популярные средства поглощения и передачи данных,
распространяемые с открытым исходным кодом.
Apache DistCp: DistCp означает «распределенная копия» (Distributed Copy)
и является частью экосистемы 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 — позволяют выполнять потоковую передачу для надежной обработки
неограниченных потоков данных.
Поглощение данных в облаке
y
Процесс поглощения данных в облаке играет важную роль в управлении большими данными. Три основных провайдера облачных платформ — AWS, GCP
(Google Cloud Platform) и Azure — предоставляют различные сервисы поглощения данных. Каждый обладает уникальной функциональностью, адаптированной для конкретных потребностей и объемов данных. Рассмотрим некоторые
специфические особенности трех облачных провайдеров.
y Сервисы поглощения данных AWS:
AWS Direct Connect: предоставляет высокоскоростное приватное сетевое
подключение к AWS, с сокращенной задержкой и повышенной емкостью
канала. Идеально подходит для передачи больших объемов данных и обес
печивает более стабильную скорость сети, чем передача по интернету;
AWS
Snowball и Snowmobile: сервисы предоставляют физические устрой
ства для передачи в AWS огромных объемов данных (терабайт и петабайт
(Пбайт)). Snowball подходит для передачи сотен терабайт; Snowmobile
может обработать до 100 Пбайт за одну передачу, благодаря чему он идеально подходит для огромных наборов данных;
448
Глава 12. Инженерия данных для архитектур решений
AWS (DMS, Database Migration Service): упрощает миграцию баз данных
y
y
в AWS. Поддерживает как гомогенные, так и гетерогенные миграции
и может обеспечивать текущую репликацию данных через механизм отслеживания изменений (CDC — change data capture).
y Сервисы поглощения данных GCP:
Google Cloud Storage Transfer Service: позволяет передавать большие
объемы данных в Google Cloud Storage из онлайн-источников данных
(Amazon S3 и HTTP/HTTPS), а также из локальных систем хранения;
Pub/Sub: передача сообщений и поглощение потоковых данных в реальном времени. Это масштабируемый и гибкий сервис, который позволяет
поглощать потоковые данные (например, журналы и данные событий)
для аналитики в режиме реального времени;
Dataflow: интегрированный сервис для поглощения и обработки данных.
Хорошо подходит для задач извлечения, преобразования, загрузки
(ETL — extract, transform, load) и обработки потоков событий в реальном
времени.
y Сервисы поглощения данных Azure:
Azure Data Factory: этот сервер интеграции данных поддерживает как
локальные, так и облачные перемещения и преобразования данных. Он
позволяет поглощать данные из различных источников, обрабатывать
их с использованием вычислительных сервисов Azure HDInsight и Azure
Batch и публиковать обработанные данные в таких хранилищах данных,
как Azure SQL Data Warehouse;
Azure Event Hubs: надежная и масштабируемая платформа для потоковой передачи данных и сервис поглощения событий. Azure Event Hubs
может обрабатывать миллионы событий в секунду. Благодаря этому он
становится идеальным решением для анализа в реальном времени данных, поступающих из различных источников: приложений, веб-сайтов,
устройств IoT и т. д.;
Azure
Import/Export: сервис спроектирован для массовой передачи
больших объемов данных в Azure Blob Storage и Azure Files и обратно.
Он использует физические диски для передачи данных, вследствие чего
подходит для сценариев, когда передача больших объемов данных по сети
может оказаться слишком медленной или затратной.
Каждый облачный провайдер предлагает уникальный набор инструментов для
различных потребностей поглощения данных, от потоковой передачи в реальном
времени до крупномасштабной миграции данных. Таким образом обеспечивается
гибкость и масштабируемость при управлении большими данными.
Задача поглощения и анализа потоковых данных также становится все более
важной. Потоковые данные более подробно рассматриваются в разделе «Хранилища потоковых данных». В нем детально разобраны принципы выбора
правильного хранилища и доступных вариантов хранения.
Поглощение данных, сохранение, обработка и аналитика
449
Хранение данных
Одна из самых распространенных ошибок при настройке хранилища для
больших данных — использование одного решения (часто РСУБД) для всех
требований к хранению данных.
В вашем распоряжении множество инструментов, но их необходимо оптимизировать для выполняемой задачи. Одно решение не всегда будет лучшим
для всех потребностей; оптимальным выбором для вашей среды может стать
комбинация решений, соблюдающих баланс между задержкой и затратами.
Идеальное решение — использовать нужный инструмент для нужной задачи.
На рис. 12.4 показаны некоторые характеристики данных и подходящие для
них варианты хранения.
Частота запросов
Высокая
Низкая
Затраты/Гбайт
Низкая
Структура данных
Архив
Поиск
Высокая
В памяти
Горячие данные
Низкая
Объект
NoSQL
Хранилище
данных
Теплые данные
Объем данных
Задержка
Холодные данные
Высокая
Рис. 12.4. Варианты хранения данных
y
y
Как показано на диаграмме, выбор хранилища данных зависит от следующих
факторов.
y Насколько данные структурированы? Соответствуют ли они конкретной,
четко сформированной схеме, как веб-логи Apache (логи обычно плохо
структурированы и не подходят для реляционных баз данных), стандартизированные протоколы данных и контрактные интерфейсы? Либо это
произвольные двоичные данные: графика, аудио, видео, документы PDF?
Или это полуструктурированные данные с общей схемой, но потенциально
высокой вариативностью записей, как в JSON или CSV?
y Насколько быстро данные должны становиться доступными для запросов?
Они предполагают сценарий реального времени, в котором решения принимаются при поступлении новых записей (как, например, при настройке
450
Глава 12. Инженерия данных для архитектур решений
y
y
y
рекламной кампании на основе коэффициента конверсии либо генерировании
рекомендаций в интернет-магазине на основе схожего поведения пользователей)? Или же сценарий с ежедневными, еженедельными либо ежемесячными
пакетами данных, как при обучении моделей, подготовке финансовых отчетов
либо отчетов о производительности продукта? Или это некий промежуточный вариант, как электронные рассылки для привлечения клиентов? Они
не требуют действий в реальном времени, и между действием пользователя
и точкой взаимодействия может пройти несколько минут или даже часов.
y Какой объем данных необходимо поглощать? Поглощаются ли данные
в том формате, в котором они поступают, — например, JSON от REST API,
записи которого занимают в лучшем случае несколько килобайт? Или это
большой массив записей, поступающих одновременно, — например, поставка
данных системной интеграции или сторонних данных? Или промежуточный
вариант — несколько микропакетов или данных посещений, агрегированных
для более эффективной обработки?
y Каков общий объем данных и скорость его роста? Вы работаете с гигабайтами, терабайтами или планируете хранить петабайты и даже экзабайты
данных? Какая часть этих данных необходима вам для целей аналитики?
Требует ли большинство ваших запросов конкретного скользящего временного окна или вам нужен механизм для запроса всего исторического
датасета?
y Каких затрат потребуют хранение и получение данных в любом конкретном месте? В любой вычислительной среде обычно существует треугольник
ограничений между производительностью, устойчивостью и затратами. Чем
выше желаемая производительность и устойчивость хранилища, тем дороже
оно обойдется. Можно выполнять быстрые запросы к петабайтам данных,
но ограничиться запросами терабайтов данных в сжатом формате для соответствия требований к затратам.
Наконец, какие аналитические запросы будут отправляться к данным? Будут
ли данные использованы для дашборда с фиксированным набором метрик
и возможной детализацией? Или они потребуются для больших агрегаций,
разворачиваемых по разным бизнес-измерениям? Или будут использоваться
для диагностики с токенизацией строк для полнотекстового поиска и анализа
закономерностей?
После определения характеристик данных и их структуры можно переходить
к оценке решений, которые могут использоваться для хранения данных. Рассмотрим их варианты.
Поглощение данных, сохранение, обработка и аналитика
451
Выбор технологии хранения данных
Как уже говорилось, возможности каждого отдельно взятого инструмента ограниченны. Лучше использовать подходящий инструмент для каждой конкретной
задачи, а озеро данных позволяет построить архитектуру Big Data с широкими
возможностями настройки для специфических потребностей.
Так, активно используемые данные должны храниться и обрабатываться в памяти, и для них подходят кэши или базы данных в памяти — например, Redis или
SAP HANA. AWS предлагает сервис ElastiCache, предоставляющий управляемую среду Redis или memcached. Базы данных NoSQL идеально подходят для
быстрых операций с записями небольшого размера — например, информации
о пользовательских сессиях или данных IoT. Базы данных NoSQL также полезны
для управления контентом при сохранении каталогов данных.
Рассмотрим самые популярные и часто используемые варианты хранения
структурированных данных.
Хранение структурированных данных
Хранение структурированных данных существует уже много лет; пожалуй, это
самая популярная технология хранения данных. Большинство транзакционных
баз данных — Oracle, MySQL, SQL Server, PostgreSQL и т. д. — работают на
уровне строк данных, что связано с частыми операциями записи из приложений.
Организации часто используют транзакционные базы данных для создания отчетов, требующих частого чтения и существенно более низкой частоты операций
записи. В отношении частого чтения все больше инноваций внедряется в области
запросов к структурированным хранилищам данных — например, колоночный
формат файлов, способствующий повышению производительности чтения для
целей аналитики.
Строковые форматы хранят данные по строкам. Запись строк данных — самый
быстрый вариант записи данных на диск, но не обязательно самый быстрый
вариант чтения, потому что приходится пропускать большое количество неактуальных данных. Колоночные форматы хранят все значения столбцов в одной
части файла. Такое решение повышает эффективность сжатия благодаря группировке однотипных данных. Производительность чтения также улучшается,
потому что при чтении можно пропускать лишние столбцы.
Рассмотрим популярные варианты хранения структурированных данных. Представим, что требуется узнать общий объем продаж за определенный месяц из
таблицы заказов, состоящей из 50 столбцов. В архитектуре, ориентированной
на строки данных, запрос сканирует всю таблицу со всеми 50 столбцами. В колоночной архитектуре запрос сканирует только столбец с данными о продажах,
что значительно повышает производительность запросов. В следующем разделе
мы подробнее рассмотрим реляционные базы данных, уделяя особое внимание
транзакционным данным и хранению данных для целей аналитики.
452
Глава 12. Инженерия данных для архитектур решений
Реляционные базы данных
y
y
y
y
РСУБД лучше подходит для приложений c обработкой транзакций в реальном
времени (OLTP). Популярные реляционные базы данных — Oracle, MSSQL,
MariaDB, PostgreSQL и т. д. Некоторые традиционные базы данных существуют
уже десятилетия. Многие приложения, включая интернет-магазины, банковские
приложения и системы бронирования отелей, строятся на основе реляционных
баз данных. Реляционные БД очень хорошо подходят для работы с транзакционными данными, когда необходимы сложные запросы на соединение таблиц.
В том, что касается поддержки транзакционных данных, реляционная БД
должна соблюдать принципы атомарности, согласованности, изолированности
и надежности (ACID).
y Атомарность (Atomicity): транзакция полностью выполняется от начала до
конца, а при возникновении ошибок полностью откатывается.
y Согласованность (Consistency): все данные должны сохраняться в базе данных при завершении транзакций.
y Изолированность (Isolation): выполняемые одновременно транзакции должны быть изолированы и не мешать друг другу.
y Надежность (Durability): в случае любых прерываний (например, сбоев
работы сети или питания) транзакция должна продолжиться с последнего
известного состояния.
Данные из реляционных БД часто выгружаются в хранилища данных (data
warehouses) для целей агрегирования и отчетности. В следующем разделе хранилища данных рассматриваются более подробно.
Хранилища данных (data warehouses)
Хранилища данных представляют собой централизованные репозитории для
хранения данных, накопленных из одного или нескольких источников. В них
содержатся текущие и исторические данные, упрощающие создание отчетов для
целей бизнес — аналитики. Хотя в хранилищах есть данные из разных систем,
их нельзя считать озерами данных (data lakes). Хранилища данных работают
только со структурированными реляционными данными, тогда как озера данных — и со структурированными, и с неструктурированными данными, например
журналами JSON и данными CSV.
Базы данных хранилищ больше подходят для приложений аналитической обработки данных в реальном времени (OLAP). Эти БД оптимизированы для
операций, связанных с чтением больших объемов данных, предоставляя возможность агрегирования и обобщения данных для извлечения ценной бизнесинформации.
Для примера возьмем сценарий с банком, который поддерживает хранилище
данных с подробной информацией о счетах клиентов, транзакциях, условиях
кредитов и филиалах. Кроме того, банк может проводить сложный анализ
Поглощение данных, сохранение, обработка и аналитика
453
объединенных данных. Запросы к хранилищу данных используются для выявления тенденций — например, определения самых популярных типов счетов
или кредитов, анализа объемов транзакций с течением времени или сравнения
шаблонов использования банковских сервисов в отделениях и в онлайн-банке.
Аналитические возможности позволяют банку принимать обоснованные решения о предложении продуктов, повышении качества обслуживания клиентов
и операционных стратегиях, что в конечном счете повышает удовлетворенность
клиентов и способствует развитию бизнеса.
Хранилища данных предоставляют функциональность быстрого агрегирования
больших объемов структурированных данных. Хотя эти технологии (такие,
как Amazon Redshift, Netezza и Teradata) проектировались для ускоренного
выполнения сложных составных запросов, их необходимо оптимизировать для
больших объемов одновременных операций записи. Таким образом, данные
должны загружаться пакетами, что не позволяет хранилищам данных предоставлять аналитику в реальном времени.
Для повышения производительности запросов современные хранилища используют колоночные базы. Например, Amazon Redshift, Snowlake и Google
BigQuery обеспечивают высокую скорость запросов благодаря колоночному
хранению и улучшенной эффективности ввода/вывода. Кроме того, системы
хранилищ данных типа Amazon Redshift ускоряют обработку запросов за счет
распределенной обработки запросов (параллельное выполнение на нескольких
узлах) и использования массово-параллельной обработки (MPP — massively
parallel processing).
Колоночное хранение повышает производительность запросов — так как данные
хранятся по столбцам, а не по строкам, открывается возможность сжатия данных, избирательного чтения и ускорения операций. Оно также оптимизирует
использование кэша процессора за счет загрузки в память актуальных данных,
повышая скорость обработки. Кроме того, колоночное хранение поддерживает
массово-параллельную обработку, при которой разные процессоры одновременно работают над разными сегментами данных, значительно повышая производительность аналитики больших наборов данных, требующей быстрого
агрегирования и фильтрации.
Решения единых хранилищ данных — такие, как Amazon Redshift — способны
обрабатывать петабайты данных и предоставляют изолированную функциональность вычисления и хранения в целях экономии. Кроме колоночного хранения,
Redshift поддерживает кодирование данных, распределение и карты зон (zone
maps) для повышения производительности запросов. Среди более традиционных инструментов единых хранилищ данных стоит упомянуть Netezza, Teradata
и Greenplum.
Использование единых хранилищ данных влечет за собой физическое отделение
данных от приложений, что обязывает архитекторов данных создавать новые
инфраструктуры на основе единых хранилищ. Ограничения традиционных
454
Глава 12. Инженерия данных для архитектур решений
единых хранилищ данных стали более заметными с ростом разнородности корпоративных данных, включающих текст, данные IoT, графику, аудио и видео.
Более того, рост популярности МО и искусственного интеллекта (ИИ) вывел
на передний план итеративные алгоритмы, которые требуют прямого доступа
к данным и не полагаются на SQL, тем самым подчеркивая ограниченность
традиционных моделей единых хранилищ данных. О том, как решать эти проблемы, вы узнаете далее в этой главе, в разделе «Проектирование архитектур
Big Data».
Базы данных NoSQL
Базы данных NoSQL — такие, как DynamoDB, Cassandra и MongoDB — решают проблемы масштабирования и производительности, с которыми часто
приходится сталкиваться при работе с реляционными базами данных. Как
следует из названия, базы NoSQL не являются реляционными. В них данные
хранятся без явного структурированного механизма связывания данных из
разных таблиц (отсутствуют соединения, внешние ключи или принудительная
нормализация).
NoSQL использует несколько моделей данных, включая колоночную модель,
пары «ключ — значение», поисковую, документную и графовую модель. Базы
данных NoSQL обеспечивают масштабируемую производительность, высокую
доступность и устойчивость. Как правило, они не требуют жесткой схемы,
и каждый элемент может иметь произвольное количество столбцов (атрибутов). Таким образом, одна строка может состоять из четырех столбцов, а другая
строка той же таблицы — из десяти столбцов. Ключ раздела (partition key)
используется для выборки значений или документов, содержащих связанные
атрибуты. Базы данных NoSQL сильно распределены и могут реплицироваться.
Они долговечны и не сталкиваются с проблемами производительности при
высокой доступности.
Сравнение баз данных SQL и NoSQL
Базы данных SQL существуют уже несколько десятилетий, и многие хорошо
знакомы с реляционными базами данных. Давайте рассмотрим некоторые
принципиальные различия между базами данных SQL и NoSQL (табл. 12.1).
В зависимости от данных для решения конкретных задач в NoSQL используются
различные способы хранения. В следующем разделе рассматриваются основные
виды баз данных NoSQL.
Поглощение данных, сохранение, обработка и аналитика
455
Таблица 12.1. Сравнение баз данных SQL и NoSQL
Свойства
Базы данных SQL
Базы данных NoSQL
Модель
данных
Реляционная модель нормализует данные в таблицы со
строками и столбцами. Схема
включает таблицы, столбцы,
отношения между таблицами,
индексы и другие элементы
Не требуют наличия фиксированной схемы, обеспечивая гибкость
хранения и извлечения данных.
Часто используют ключ раздела
для обращения к значениям из наборов столбцов. Эта разновидность
БД хорошо подходит для хранения
полуструктурированных данных,
включая такие форматы, как JSON,
XML и другие разновидности документов (например, каталоги данных и файловые индексы)
Транзакция Соответствуют набору свойств
ACID транзакционных систем
Жертвуют некоторыми свойствами
ACID, типичными для традиционных РСУБД, для упрощения горизонтального масштабирования
и повышения гибкости моделей
данных
Производительность
Использовались для оптимизации дискового пространства,
когда оно стоило дорого, и минимизировали объем хранения.
Производительность в основном зависела от диска. Оптимизация производительности
запросов требует создания индексов и изменения структуры
таблиц
Производительность в большой
степени зависит от таких факторов,
как размер используемого аппаратного кластера, сетевая задержка
и схема взаимодействия приложения с базой данных
Масштабирование
Проще всего масштабируются
по вертикали за счет повышения мощности оборудования.
Условие охвата распределенных
систем (например, при шардировании данных) потребует дополнительных усилий
Проектируются с расчетом на горизонтальное масштабирование
с использованием распределенных
кластеров экономичного оборудования. Такой подход направлен на
повышение пропускной способности при минимальном увеличении
задержки
456
Глава 12. Инженерия данных для архитектур решений
Виды баз данных NoSQL
y
y
y
y
Основные разновидности баз данных NoSQL:
y колоночные: Apache Cassandra и Apache HBase — популярные колоночные
базы данных. Колоночное хранилище данных позволяет сканировать при запросе конкретный столбец (вместо сканирования всей строки). Представим,
что таблица товарных запасов содержит десять столбцов и один миллион
строк и вы хотите запросить количество имеющихся в наличии товаров.
В таком случае колоночная база данных применит запрос к столбцу с количеством единиц товара и не будет сканировать всю таблицу;
y документоориентированные: самые популярные в этой категории —
MongoDB, Couchbase, MarkLogic, DynamoDB, DocumentDB и Cassandra.
Такая БД может использоваться для хранения полуструктурированных
данных в форматах JSON и XML;
y графовые: наиболее распространенные графовые базы данных — Amazon
Neptune, JanusGraph, TinkerPop, Neo4j, OrientDB, GraphDB и GraphX в Spark.
В графовых БД хранятся вершины и связи между вершинами, называемые
ребрами. Графы могут строиться на основе как реляционных, так и нереляционных баз данных;
y хранилища пар «ключ — значение» в памяти: популярные представители
этой категории — Redis и Memcached. Они хранят данные в памяти для
приложений с интенсивным чтением. Любой запрос от приложения сначала
попадает в базу данных в памяти, и, если данные доступны в кэше, нет необходимости обращаться к основной БД. База данных в памяти подходит
для хранения информации пользовательских сессий; к ним обращаются
со сложными запросами и часто запрашивают такие данные, как пользовательские профили.
У баз данных NoSQL много практических применений, но для проведения поиска в них все данные необходимо проиндексировать. В следующем разделе более
подробно рассматриваются поисковые хранилища данных.
Поисковые хранилища данных
Сервис Elasticsearch — одна из самых популярных поисковых систем для больших данных (например, данных посещений и анализа журналов). Поисковые
системы хорошо работают с «теплыми» данными, которые могут запрашиваться
ситуативно по любому количеству атрибутов, включая строковые токены.
Amazon OpenSearch Service предоставляет функциональность поиска и поддержку кластеров Elasticsearch с открытым исходным кодом, включая доступ
к API. Также предлагается механизм визуализации Kibana для индексируемых
хранилищ данных. AWS управляет емкостью, масштабированием и коррекцией
кластеров, избавляя от любых накладных расходов на эксплуатацию. Поиск
в журналах и их анализ — популярный сценарий работы с большими данными,
Поглощение данных, сохранение, обработка и аналитика
457
при котором OpenSearch используется для анализа журнальных данных вебсайтов, парков серверов, датчиков IoT и т. д. OpenSearch и Elasticsearch находят применения в самых разных отраслях, таких как банковское дело, игры,
маркетинг, мониторинг приложений, рекламные технологии, обнаружение попыток мошенничества, рекомендательные технологии и IoT. Также доступны
сервисы поиска на базе машинного обучения — такие, как Amazon Kendra; они
предоставляют продвинутые возможности поиска с использованием обработки
естественных языков (NLP, natural language processing).
Хранилища неструктурированных данных
С точки зрения требований к хранилищам неструктурированных данных
Hadoop — идеальный вариант: эта система хорошо масштабируется, расширяется и обладает исключительной гибкостью. Она может работать на оборудовании потребителя, имеет обширную экосистему инструментов и отличается
экономичностью. Hadoop использует модель главных и дочерних узлов: данные
распределяются между несколькими дочерними узлами, а главный узел координирует задания для выполнения запросов к данным.
Система Hadoop основана на технологии MPP, что позволяет ей быстро выполнять запросы с данными любых типов — как структурированными, так
и неструктурированными.
При создании кластера 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
y
y
y
y
y
y
Стандартный сценарий использования — поиск элементов, похожих на заданный
элемент. Например, база данных может быстро вернуть изображения, сходные
с изображением из запроса. Векторные базы данных могут обеспечивать работу
рекомендательных систем, сопоставляя профили пользователей с векторами продуктов, чтобы порекомендовать подходящие элементы. Они могут эффективно
обрабатывать и запрашивать крупномасштабные текстовые данные, преобразованные в векторное пространство для применения в сфере NLP. Основные
преимущества векторных баз данных:
y скорость и эффективность: векторные БД, адаптированные для работы
с многомерными данными, могут выполнять поиск по подобию намного
быстрее, чем традиционные базы данных;
y масштабируемость: векторные БД проектируются для масштабирования по
размеру данных. Это очень важно для приложений МО, в которых обычно
используются очень большие наборы данных;
y интеграция с пайплайнами МО/ИИ: бесшовная интеграция с потоками
операций МО, разрешающая прямые запросы к векторным данным и манипуляции с ними.
Впрочем, у векторных баз данных имеются и недостатки:
y сложность: управление и индексирование многомерных векторных данных
могут быть достаточно непростой задачей;
y ресурсоемкость: такие базы данных могут требовать значительных вычислительных ресурсов, особенно для больших наборов данных;
y недостаточная зрелость технологии: векторные базы данных появились
относительно недавно, поэтому экосистема вокруг них может быть не такой
зрелой, как у традиционных баз данных, что может повлиять на решение
о внедрении в корпоративных средах.
Векторные БД являются частью более широкой тенденции к использованию
специализированных баз данных, адаптированных для конкретных типов данных
и рабочих нагрузок, особенно в контексте МО и ИИ. Они представляют собой
важный этап в развитии технологий баз данных, которые стремятся не отставать
от достижений в области обработки данных и аналитики. По мере становления
эта технология с большой вероятностью станет неотъемлемой частью инфраструктуры данных в организациях со значительными вложениями в МО и ИИ.
Хранилище блокчейн-данных
Технология блокчейна, обычно ассоциируемая с криптовалютами, предлагает
революционный подход к управлению данными и обработке транзакций в различных отраслях, не только в финансах. Хранилища блокчейн-данных предоставляют мощный механизм децентрализованной проверки данных, который, по
сути, принципиально меняет подход к сохранению и проверке транзакций в разных отраслях. Например, в кадастровой системе на базе блокчейн-технологий
460
Глава 12. Инженерия данных для архитектур решений
каждая операция продажи или покупки недвижимости регистрируется в общем
реестре и мгновенно становится доступной и проверяемой для всех сетевых
участников. Такая прозрачность отличается от традиционных централизованных
систем, где данными управляет один авторитетный источник; она снижает риск
мошенничества и повышает доверие между участниками.
Основные характеристики блокчейна — неизменяемость и безопасность — расширяют возможности его применения между отраслями. Например, в здравоохранении
блокчейн гарантирует, что после ввода данных пациента в систему эти данные останутся неизменными и безопасными. Такая неизменяемость чрезвычайно важна для
профессиональных медиков, которые выбирают курс лечения, полагаясь на точные
исторические данные. Кроме того, криптографическая безопасность блокчейна
защищает чувствительную информацию о здоровье, предоставляя доступ только
авторизованным пользователям и обеспечивая конфиденциальность пациентов.
Благодаря этим свойствам блокчейн становится бесценным инструментом в тех
отраслях, где особенно важны целостность и безопасность данных.
y
y
y
В достижении неизменяемости ключевую роль играют сети блокчейна. Фактически они превращаются в децентрализованный цифровой реестр, в котором
регистрируются транзакции от разных компьютеров; при этом используется механизм, обеспечивающий целостность и безопасность данных. В блокчейн-сетях
транзакции группируются в блоки; каждый блок связывается с предыдущим,
образуя цепочку. Такая структура значительно усложняет изменение информации задним числом без согласия всех сетевых участников. Ниже перечислены
основные разновидности блокчейн-сетей.
y Публичные блокчейн-сети: Ethereum часто используется для децентрализованных приложений (DApps) и смарт-контрактов. Сеть Ethereum является открытой, любой желающий может присоединиться и участвовать
в ее работе. Например, разработчик может создать DApp-приложение для
децентрализованных финансов (DeFi) в сети Ethereum, давая возможность
пользователям участвовать в финансовых транзакциях без привлечения
традиционных банков.
y Частные блокчейн-сети: доступ к сетям этого типа ограничен. Их работой
управляет организация, предоставляя большую степень конфиденциальности и контроля. Фармацевтическая компания может использовать частную
блокчейн-сеть для управления процессом производства лекарств. Доступ
к блокчейну ограничивается исследователями и надзорными органами, что
обеспечивает конфиденциальность чувствительных данных.
y Блокчейн-сети консорциумов: блокчейн-сети, находящиеся под управлением
нескольких организаций и сохраняющие баланс между децентрализацией
и управлением. Пример — группа компаний-перевозчиков, сформировавших
консорциум для управления общей блокчейн-сетью. Эта блокчейн-сеть может
использоваться для отслеживания грузов по всему миру, при этом каждая
компания будет поддерживать свой узел в этой сети.
Поглощение данных, сохранение, обработка и аналитика
461
Такие облачные провайдеры, как AWS, предлагают блокчейн как сервис, упрощая
настройку блокчейн-сетей и управление ими. Amazon QLDB (Quantum Ledger
Database) — пример централизованной базы данных-реестра, предоставляющей
неизменяемый и криптографически проверяемый протокол транзакций. Популярные управляемые блокчейн-сервисы, включая AMB (Amazon Managed
Blockchain), R3 Corda, Ethereum и Hyperledger, обслуживают различные потребности — от финансовых транзакций до управления цепочками поставок.
Обработка потоковых данных когда-то считалась нишевой технологией, но
сейчас ее популярность растет, поскольку каждая организация сталкивается
с задачей быстрого получения аналитической информации после обработки
данных в реальном времени. В следующем разделе хранилища потоковых данных
рассматриваются более подробно.
Хранилища потоковых данных
Потоковые данные поступают непрерывно, без начала и конца. Большой объем
данных от различных ресурсов реального времени (биржевые котировки, беспилотные автомобили, умные дома, социальные сети, электронная коммерция,
игры, приложения для поездок и т. д.) необходимо быстро сохранять и обрабатывать. Netflix предоставляет рекомендации в реальном времени на основании
просматриваемого контента, а Lyft использует потоковые данные для связи
пассажиров с водителем в реальном времени.
y
Хранение и обработка потоковых данных — непростая задача, поскольку в систему поступает непрерывный поток данных и емкость хранилища невозможно
предсказать заранее. Наряду с большим объемом, потоковые данные характеризуются очень высокой скоростью; это требует масштабируемой системы
хранения, которая способна хранить данные и предоставлять средства для
их воспроизведения. Со временем потоки данных начинают требовать очень
высоких затрат на обслуживание и высокой сложности управления. Самые
популярные сервисы хранения потоковых данных — Apache Kafka, Apache
Flink, Apache Spark Structured Streaming, Apache Samza и Amazon Kinesis. AWS
предоставляет управляемую разновидность Kafka, называемую Amazon Managed
Streaming for Kafka. Рассмотрим подробнее технологии поглощения и хранения
потоковых данных.
y Amazon Kinesis предоставляет три основных сервиса:
KDS (Kinesis Data Streams) используется для хранения необработанного
потока данных для выполнения последующей обработки нужных записей;
KDF (Kinesis Data Firehose) упрощает перемещение записей в общие
аналитические среды: Amazon S3, Elasticsearch, Redshift, Splunk и т. д.
Firehose автоматически буферизует все записи в потоке и сбрасывает его
в приемник как один файл или набор записей в зависимости от порога
по времени или размеру записи, который можно настроить (или того,
который будет достигнут первым);
462
Глава 12. Инженерия данных для архитектур решений
KDA (Kinesis Data Analytics) сначала проводит аналитику потоко-
y
y
y
y
вых записей с использованием Apache Flink. Вывод может переходить
в другие потоки, создаваемые для построения бессерверного потокового
пайплайна.
y Amazon MSK (Managed Streaming for Kafka) — полностью управляемый
безопасный сервис с высокой доступностью. Amazon MSK выполняет
приложения Apache Kafka в облаке AWS, при этом опыт управления
инфраструктурой Apache не нужен. Amazon MSK предоставляет управляемый кластер Apache Kafka с кластером ZooKeeper для управления
конфигурацией и создания производителя/потребителя для поглощения
и обработки данных.
y Apache Flink — еще одна платформа с открытым исходным кодом для потоковой передачи данных и обработки пакетных данных. Flink представляет
собой ядро потоковой передачи, которое может обрабатывать ограниченные
и неограниченные потоки данных. У ограниченного потока данных определены начало и конец, а у неограниченного имеется начало, но нет конца.
Flink может выполнять пакетную обработку в своем потоковом ядре и поддерживает оптимизации пакетов.
y Apache Spark Streaming обеспечивает поглощение живых потоков данных
с высокой пропускной способностью, отказоустойчивостью и масштабируемостью. Spark Streaming разделяет входные потоки данных на пакеты, прежде
чем отправлять их ядру Spark для обработки. Spark Streaming использует
абстракции DStream — последовательности устойчивых распределенных
наборов данных (RDD, Resilient Distributed Dataset).
y Apache Kafka — одна из самых популярных потоковых платформ с открытым
исходным кодом, которая обеспечивает публикацию потока данных и подписку на него. Кластер Kafka сохраняет поток в топике Kafka. Производитель
может публиковать данные в топике Kafka, а потребители — извлекать выходной поток данных путем подписки на топик Kafka.
Потоковое хранилище должно сохранять непрерывный поток данных и поддерживать возможность сохранения исходного порядка в случае необходимости. Потоковые архитектуры более подробно рассматриваются далее в разделе
«Архитектура потоковых данных».
Хранение данных в облаке
Облачные хранилища данных являются одним из важнейших аспектов современной IT-инфраструктуры. Они отличаются масштабируемостью, гибкостью
и экономичностью. Ведущие провайдеры облачных платформ — AWS, GCP
и Azure — предоставляют различные варианты хранения данных для разных
потребностей, от простого хранения файлов до сложных баз данных и решений
единых хранилищ данных. Ниже перечислены ключевые характеристики облачных хранилищ данных на этих платформах.
Хранение данных в облаке
463
y
y AWS:
Amazon S3 (Simple Storage Service): высокомасштабируемый сервис
y
y
хранения объектов, известный своей высокой доступностью данных,
езопасностью и производительностью. Сервис Amazon S3 гибок, он идеб
ально подходит для хранения любого объема данных, применимых в самых разных сценариях: веб-сайтах, мобильных приложениях, резервном
копировании и восстановлении, архивации, корпоративных приложениях,
устройствах IoT и аналитике больших данных.
Amazon EBS (Elastic Block Store): EBS предлагает тома блокового уровня
для использования с экземплярами EC2. Они особенно хорошо подходят для данных, требующих стабильной производительности с низкой
задержкой — например, баз данных или систем планирования ресурсов
предприятия (ERP, Enterprise Resource Planning).
Amazon RDS (Relational Database Service): RDS упрощает настройку,
эксплуатацию и масштабирование реляционной базы данных в облаке.
Сервис предлагает экономичное решение с изменяемой емкостью, а также
автоматизацию многих времязатратных задач администрирования баз
данных.
Amazon S3 Glacier: сервис предоставляет безопасное, надежное и низкозатратное облачное хранилище для архивации и долгосрочного резервного
копирования. Amazon S3 Glacier идеально подходит для хранения данных,
к которым обращаются относительно редко; таким образом, это решение
ориентировано на данные с большим периодом удержания.
GCP:
y
Google Cloud Storage: объектное хранилище для компаний любого
размера. Решение обладает высокой масштабируемостью и гибкостью,
предоставляя безопасное и долгосрочное хранилище для приложений
и рабочих нагрузок с повышенным спросом.
Persistent Disk: блоковое хранилище для экземпляров Google Compute
Engine. Предоставляет высокопроизводительное пространство SSD
и HDD, которое может присоединяться к экземплярам, работающим
в Compute Engine или GKE (Google Kubernetes Engine).
Cloud SQL: полностью управляемый сервис баз данных, упрощающий настройку, обслуживание, управление и администрирование реляционных
баз данных в Google Cloud.
Google Cloud Bigtable: масштабируемый, полностью управляемый сервис
баз данных NoSQL для больших аналитических и эксплуатационных
рабочих нагрузок.
y Microsoft Azure:
Azure Blob Storage: объектное хранилище Azure, спроектированное для
облачной среды. Оно отлично подходит для хранения больших объемов
неструктурированных данных — например, текстовых или двоичных.
464
Глава 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
Необработанные
данные
Обработанные
данные
Amazon
Athena
Amazon
Athena
Redshift
Amazon
Quick Sight
Рис. 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. К этим файлам
легко обращаться с запросами без изменения существующего потока данных.
В следующем разделе рассматриваются популярные инструменты обработки
данных.
Выбор технологии для обработки и анализа данных
y
y
y
Ниже перечислены самые популярные технологии обработки данных, которые
применяются для выполнения преобразований и обработки Big Data.
y Apache Hadoop использует распределенную архитектуру обработки, в которой задача передается кластеру серверов. Каждая часть работы, распределенной на серверы кластера, может выполняться и повторно выполняться на
любом сервере. Серверы кластера часто используют HDFS для локального
хранения обрабатываемых данных. Фреймворк Hadoop берет большое задание, разбивает его на отдельные задачи и обрабатывает их параллельно.
Он обеспечивает массовую масштабируемость по огромному количеству
кластеров Hadoop. Система спроектирована для отказоустойчивости, и каждый рабочий узел периодически сообщает свой статус первичному узлу.
Первичный узел может перераспределять работу из кластера, от которого
не был получен положительный ответ. Самые популярные фреймворки, используемые с Hadoop, — Hive, Presto, Pig и Spark.
y Apache Spark — фреймворк обработки данных в памяти. Apache Spark
представляет собой систему массово-параллельной обработки с разными
исполнителями, которые могут разобрать задание Spark на задачи и выполнять их параллельно. Чтобы повысить параллелизм задания, добавьте узлы
в кластер. Spark поддерживает пакетные, интерактивные и потоковые источники данных, использует направленные ациклические графы (DAG, directed
acyclic graphs) для представлений стадий во время выполнения работы.
DAG отслеживает данные и преобразования наследования между заданиями
и эффективно минимизирует ввод/вывод за счет хранения кадров данных
в памяти. Spark также поддерживает секционирование для предотвращения
лишних передач данных, создающих нагрузку на сеть.
y (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), OpenID, OAuth и SAML2 (Security Assertion
Markup Language 2.0). HUE позволяет просматривать журналы в реальном
y
y
y
y
y
y
y
y
y
y
Хранение данных в облаке
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. Инженерия данных для архитектур решений
y
y
включает некоторые базовые разновидности диаграмм. Система чрезвычайно
гибка в отношении произвольного вывода от бэкенда любого языка вывода,
который можно распознавать и визуализировать.
y Ganglia — инструмент мониторинга кластеров Hadoop. Для применения
необходимо установить его в кластере при запуске. Ganglia UI работает на
первичном узле, для него можно использовать туннель SSH. Ganglia — проект
с открытым исходным кодом, разработанный для мониторинга кластеров без
влияния на их производительность. С помощью Ganglia можно исследовать
производительность отдельных серверов кластера и кластеров в целом.
y JupyterHub — многопользовательский вариант Jupyter. Jupyter Notebook —
один из самых популярных инструментов среди специалистов в области
данных для целей инженерии данных и МО. Сервер JupyterHub предоставляет каждому пользователю веб-IDE Jupyter Notebook. Пользователи
могут одновременно писать и выполнять код в своих блокнотах Jupyter для
исследовательской аналитики данных.
Обработка данных в облаке
y
y
Обработка данных в облаке — фундамент современных стратегий Big Data и аналитики. Три основных провайдера облачных сервисов — AWS, GCP и Azure —
предоставляют различные сервисы обработки данных, каждый из которых
обладает своими возможностями и функциональностью. Ниже перечислены
некоторые отличительные особенности каждого варианта.
y 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 без требований к управлению инфраструктурой.
y GCP Data Processing Services:
Google BigQuery: полностью управляемое бессерверное решение единого
хранилища данных, спроектированное для быстрого и экономичного выполнения запросов SQL к большим наборам данных. Сервис BigQuery
Хранение данных в облаке
469
y
особенно ориентирован на аналитику в реальном времени и может эффективно обрабатывать потоковые данные.
Cloud Dataflow: полностью управляемый сервис, предназначенный для
обработки данных в потоковом и пакетном режиме. Сервис, построенный
на базе Apache Beam, предлагает унифицированную модель программирования, упрощающую разработку пайплайнов параллельной обработки
данных. Он хорошо подходит для обработки широкого спектра задач от
разных процессов ETL для пакетных рабочих нагрузок и потоковых рабочих нагрузок реального времени.
Cloud Dataprep: продвинутый сервис данных, предоставляющий возможности для визуального исследования, очистки и подготовки как
структурированных, так и неструктурированных данных для анализа.
Сервис CloudDataprep, бесшовно интегрирующийся с BigQuery и Cloud
Dataflow, расширяет возможности исследования и преобразования
данных.
y Azure Data Processing Services:
Azure HDInsight: полностью управляемый облачный сервис, упрощающий обработку больших объемов данных популярными фреймворками
с открытым исходным кодом — такими, как Apache, Hadoop, Spark, Kafka
и HBase. Подходит для разных сценариев — ETL, единых хранилищ данных, МО, IoT и т. д.
Azure Databricks: быстрая и простая аналитическая платформа на базе
Apache Spark, ориентированная на совместную работу. Глубоко интегрируется с другими сервисами Azure и предоставляет унифицированную
платформу для процессов ETL, потоковой аналитики, МО и единых
хранилищ данных.
Azure
Synapse Analytics: всеобъемлющий аналитический сервис, объ
единяющий функциональность Big Data с хранилищами данных. Предоставляет целостный опыт работы по поглощению, подготовке, управлению
и поставке данных для приложений бизнес-аналитики и МО. Azure Synapse
Analytics делает возможными одновременные запросы к озерам и базам
данных, упрощая процессы анализа.
Сервисы обработки данных каждого облачного провайдера проектировались
для удовлетворения конкретных потребностей в жизненном цикле данных, от
обработки и преобразования больших наборов данных до интерактивных запросов и аналитики реального времени. Благодаря такому разнообразию бизнес
может выбрать наиболее подходящие инструменты и платформы в зависимости
от своих специфических потребностей в обработке данных и целей.
Анализ и обработка данных — обширные темы, требующие отдельной книги.
В этом разделе приведен общий обзор популярных и распространенных инструментов обработки. Существует и большое количество других инструментов,
как проприетарных, так и распространяемых с открытым исходным кодом.
470
Глава 12. Инженерия данных для архитектур решений
Вы, как архитектор решений, должны иметь о них представление, чтобы подобрать подходящий для вашей организации.
Бизнес-аналитикам требуется создавать отчеты и дашборды, выполнять ситуативные (ad hoc) запросы и проводить анализ результатов, чтобы получать
ценные инсайты. Тема визуализации данных более подробно рассматривается
в следующем разделе.
Визуализация данных
Аналитика данных используется для ответа на ключевые бизнес-вопросы: выручка по клиентам, прибыль по регионам, реферальный трафик с рекламных
площадок и т. д. В пайплайне Big Data огромные объемы данных собираются из
разных источников. Компаниям важно также получать информацию о запасах
товаров по регионам, прибыльности и величине потерь от мошенничества. Некоторые данные, непрерывно собираемые для целей комплаенса, также могут
использоваться для генерирования бизнес-выводов.
Две самые важные проблемы инструментов бизнес-аналитики — стоимость
реализации решений и время, затраченное на нее. Рассмотрим некоторые технологии визуализации данных.
Технологии визуализации данных
y
y
Ниже перечислены некоторые популярные платформы визуализации данных,
которые помогут подготовить отчеты с наглядным представлением данных в соответствии с требованиями бизнеса
y Amazon QuickSight — облачный инструмент бизнес-аналитики для визуализации данных корпоративного уровня. Поставляется с разнообразными
шаблонами графиков и диаграмм: линейными графиками, круговыми диаграммами, древовидными картами, тепловыми картами, гистограммами
и т. д. Amazon QuickSight использует ядро кэширования SPICE (Superfast, Parallel, In-memory Calculation Engine), которое ускоряет создание
визуализаций. Также поддерживаются операции подготовки данных:
переименование и удаление полей, изменение типов данных и создание
новых вычисляемых полей. QuickSight также предоставляет визуализации на базе результатов МО и другие функции на базе МО — например,
автопрогнозирование.
y Kibana — инструмент визуализации данных, распространяемый с открытым исходным кодом. Применяется для визуализации потоковых данных
и анализа журналов. Kibana предоставляет интеграцию с Elasticsearch и использует ее по умолчанию для поиска данных на базе сервиса Elasticsearch.
Как и другие инструменты бизнес-аналитики, Kibana предлагает популярные
средства визуализации: гистограммы, круговые диаграммы, тепловые карты
и т. д., а также встроенную геопространственную поддержку.
Проектирование архитектур Big Data
471
y
y Tableau — один из самых популярных инструментов бизнес-аналитики для
y
y
y
визуализации данных. В нем используется ядро визуальных запросов, оптимизированное таким образом, чтобы большие данные анализировались
быстрее традиционных запросов. Tableau предоставляет интерфейс, основанный на перетаскивании элементов (drag-and-drop), и возможность слияния
данных из нескольких ресурсов.
y Spotfire выполняет обработку в памяти для ускорения ответа, поддерживая
обширные наборы данных из разных ресурсов. Spotfire позволяет нанести
данные на географическую карту и опубликовать ее в Twitter. Если включить рекомендации Spotfire, система автоматически проанализирует данные
и предложит лучший вариант их визуализации.
y Jaspersoft поддерживает отчеты и аналитику самообслуживания. Также
поддерживается визуальный конструктор, основанный на перетаскивании
(drag-and-drop).
y Power BI — популярный инструмент бизнес-аналитики от компании
Microsoft. Он предоставляет возможности аналитики самообслуживания
с различными вариантами визуализации.
Визуализация данных — исключительно важная и обширная тема. Вы, как архитектор решений, должны разбираться в доступных инструментах и выбирать
такое решение визуализации данных, которое наилучшим образом подходит для
ваших бизнес-требований.
Вы познакомились с компонентами пайплайнов данных, от поглощения, хранения и обработки до визуализации. В следующем разделе мы объединим эти
компоненты, и вы узнаете, как оркестрировать архитектуру Big Data.
Проектирование архитектур Big Data
Big Data-решения включают функции поглощения данных, преобразования для
хранения, обработки и визуализации. В повседневных бизнес-операциях этапы
повторяются. Для выстраивания этих рабочих процессов можно использовать
технологии с открытым исходным кодом или облачные технологии, о которых
вы узнали в предыдущих разделах.
y
y
y
Сначала необходимо понять, какой архитектурный стиль подходит для вас;
для этого необходимо двинуться в обратном направлении от бизнес-сценария.
Рекомендуется составить представление о конечном пользователе своей архитектуры Big Data и создать условного персонажа; это поможет лучше понять
требования. Чтобы определить ключевых целевых персонажей для архитектуры
данных, необходимо ответить на следующие вопросы.
y В каких командах, отделах или подразделениях организации они работают?
y Каким уровнем квалификации в области анализа и инженерии данных они
обладают?
y Какими инструментами они обычно пользуются?
472
Глава 12. Инженерия данных для архитектур решений
y
y Следует ли ориентироваться на работников, клиентов или партнеров орга-
y
y
y
y
y
y
y
y
y
y
y
y
низации?
Если взять для примера анализ торговой сети, можно определить следующих
персонажей.
y Продакт-менеджер: является владельцем линейки продуктов/кода, но видит
объем продаж только своего продукта.
y Директор магазина: знает оборот продаж и ассортимент одного магазина (то
есть видит только свой магазин).
y Администратор: должен иметь доступ ко всем данным.
y Аналитик данных: должен иметь доступ ко всем данным, исключая персональную информацию.
y Менеджеры по удержанию клиентов: должны понимать закономерности
клиентского трафика.
y Специалисты по data science: необходим доступ к необработанным и обработанным данным для создания рекомендаций и прогнозов.
После определения персонажей следует составить для них бизнес-сценарии.
Приведем несколько примеров.
y Тренды покупательской активности: анализ количества клиентов, увеличивающих или сокращающих свои траты со временем. Характеризуйте этих
клиентов на основании структуры их расходов.
y Категории роста среди потребителей с увеличивающимися расходами: определите, в каких категориях продуктов или сервисов наблюдаются более высокие темпы роста среди клиентов, увеличивающих свои расходы со временем.
y Категории замедления среди потребителей со снижающимися расходами:
определите, в каких категориях наблюдается снижение вовлеченности клиентов, уменьшающих свои расходы со временем.
y Влияние демографии на расходы: исследуйте, какие демографические факторы (размер домохозяйства, наличие детей, уровень доходов и т. д.) влияют
на характер трат клиентов. Кроме того, оцените, какие демографические
факторы влияют на вовлеченность по конкретным категориям продуктов
или сервисов.
y Эффективность директ-маркетинга: выясните, существуют ли убедительные
доводы в пользу того, что кампании директ-маркетинга помогают повысить
вовлеченность клиента.
y Влияние директ-маркетинга на другие категории: оцените, оказывает ли
директ-маркетинг в одной категории положительный эффект на вовлеченность клиентов в других категориях.
После выяснения деталей бизнес-сценариев следующим важным этапом создания архитектуры данных станет понимание закономерностей обращений
к данным и политик хранения. Эти параметры можно проанализировать с помощью следующих вопросов.
Проектирование архитектур Big Data
473
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
Как часто ключевые пользователи и персонажи запрашивают свои отчеты?
Каковы их ожидания относительно актуальности данных?
Каковы их ожидания относительно детализации данных?
К какой части данных они чаще всего обращаются для анализа?
Как долго данные должны храниться для аналитических целей?
В какой момент данные будут считаться утратившими актуальность и могут
быть исключены из среды озера данных?
При работе с данными всегда приходится учитывать множество нюансов.
В каждой стране и каждом регионе действуют свои локальные нормативные
требования, которые должен понимать архитектор данных:
y Какие требования комплаенса предъявляет бизнес?
y Распространяются ли на вас требования локальности данных, конфиденциальности или скрытия данных?
y Кому разрешено видеть записи и атрибуты в датасете?
y Как будет обеспечено удаление записей по требованию?
y Где будут храниться данные (локальное/региональное/глобальное хранилище)?
Вы, как архитектор данных, также должны учитывать фактор окупаемости и его
влияние на бизнес-решения. Для этого стоит ответить на следующие вопросы.
y Какие основные бизнес-процессы и решения поддерживают ваши озера
данных?
y Какой уровень детализации необходим для этих решений?
y Как задержка данных влияет на бизнес-решения?
y Как вы собираетесь оценивать успех?
y Какую окупаемость вы планируете за затраченное время и материалы?
В конечном счете вам требуется архитектура данных, которая допускала бы
гибкий выбор технологических решений — например, за счет использования
облачных управляемых сервисов и технологий с открытым исходным кодом.
Big Data-решения должны строиться так, чтобы применять параллелизм
для достижения высокого уровня производительности и масштабирования.
Следует позаботиться о том, чтобы любые компоненты пайплайна Big Data
могли независимо масштабироваться по возрастанию и убыванию для возможности их корректировки в соответствии с разными рабочими нагрузками
бизнеса.
y
y
y
y
y
y
Чтобы задействовать весь потенциал выбранного вами решения, следует обес
печить его совместимость с существующими приложениями, чтобы компоненты
архитектуры больших данных также использовались для задач МО и корпоративных BI-решений (business intelligence). Это позволит вам создавать интегрированные решения, совмещающие разные рабочие нагрузки данных. В следующем
разделе рассматриваются некоторые паттерны архитектур Big Data.
474
Глава 12. Инженерия данных для архитектур решений
Архитектура озера данных (data lake)
Озеро данных служит центральным репозиторием, который аккумулирует
структурированные и неструктурированные данные разнообразных типов, используемых в корпорации. Концепция озера данных появилась как решение
для переноса всех корпоративных данных в экономичную систему хранения
(например, Amazon S3). К данным в озере можно обращаться через обобщенные
API и открытые форматы файлов, включая Apache Parquet и ORC (Optimized
Row Columnar). Этот метод сохраняет данные в исходной форме, используя
открытые форматы файлов для приложений прямой аналитики и МО.
Озеро данных становится популярным способом хранения и анализа больших
объемов данных в централизованном репозитории. Данные могут сохраняться
«как есть» в текущем формате, без необходимости преобразовывать их к заранее
определенной схеме, что повышает скорость поглощения данных. Как показано
на рис. 12.6, озеро данных является единым источником достоверных данных
в организации.
BI (Бизнес-аналитика)
DQ (data quality)запросы
Машинное обучение
Обработка Big Data
Интерактивность
В реальном времени
Каталог
Озеро данных
OLTP
ERP
CRM
LOB
Устройство
Веб
Датчики
Рис. 12.6. Объектное хранилище для озера данных
Социальные
сети
Проектирование архитектур Big Data
475
y
y
y
y
Основные преимущества озер данных:
y поглощение данных из различных источников: озера данных позволяют хранить и анализировать данные из разнообразных источников — реляционных
и нереляционных баз данных и потоков — в одном централизованном приемнике, который становится единым источником достоверных данных (source
of truth). Это ответ на такие вопросы, как «Почему данные распределены во
многих местах?» и «Где находится единый источник достоверных данных?»;
y сбор и эффективное хранение данных: озеро данных может поглотить любую
структуру данных, включая полуструктурированные и неструктурированные
данные, без обязательной схемы. Это ответ на вопрос «Как быстро поглотить
данные из различных источников в разных форматах и эффективно сохранить их в масштабе?»;
y восходящее масштабирование по объему генерируемых данных: озера
данных позволяют разделить уровни хранения и вычисления, чтобы каждый
компонент мог масштабироваться по отдельности. Это ответ на вопрос «Как
организовать масштабирование по объему генерируемых данных?»;
y применение аналитики к данным из разных источников: в озере данных можно определить схему для чтения и создать централизованный каталог данных
для информации, полученной из разных источников, что дает возможность
быстро проводить ситуативный анализ. Это ответ на вопрос «Смогу ли я применять разные методы аналитики и обработки к одним и тем же данным?»
Для озера данных предпочтительно иметь решение для неограниченного масштабируемого хранилища данных. У разделения обработки и хранения есть много
преимуществ, включая возможность обработки и анализа одних данных с применением разных инструментов. Хотя это может потребовать лишнего шага загрузки
данных в нужную программу, Amazon S3 в качестве центрального хранилища
данных предоставляет еще больше преимуществ, чем традиционные варианты
хранения. На рис. 12.7 показано озеро данных, использующее сервисы AWS.
На диаграмме изображено озеро данных, работающее Amazon S3. Данные поглощаются централизованным хранилищем из разных ресурсов (например,
реляционных баз данных и мастер-файлов данных). На уровне необработанных данных все данные хранятся в исходном формате. Затем они проходят
каталогизацию и преобразование с использованием сервиса AWS Glue. AWS
Glue — бессерверное решение для каталогизации данных и процессов ETL, построенное на базе Spark в облачной платформе AWS. Бот AWS Glue упрощает
процесс каталогизации хранилищ данных. Он автоматически сканирует источники данных, идентифицирует форматы данных и определяет схемы, создавая
и заполняя каталог данных информацией метаданных. Бот классифицирует
данные, чтобы понять их формат и структуру, и создает определения таблиц
в каталоге данных, что упрощает построение запросов для аналитики. После
преобразования данные сохраняются на уровне обработанных данных озера,
что делает возможным их дальнейшее потребление.
476
Глава 12. Инженерия данных для архитектур решений
Облако AWS
VPC
Озеро данных
Озеро данных
(хранилище)
Частная подсеть
AWS Database
Migration Service
Amazon RDS
Необработанные
данные
Необработанные
данные
Профилирование
и обработка данных
Бот Glue
AWS Glue
Бот Glue
Каталог
данных
AWS Glue
Мастер-файл данных
Потребитель
Amazon Athena
Amazon QuickSight
Рис. 12.7. Архитектура озера данных на платформе AWS
Инженеры данных могут выполнять ситуативные запросы с использованием
Amazon Athena — бессерверного сервиса запросов, построенного на базе управляемых экземпляров Presto, — и использовать SQL для прямых запросов данных
из Amazon S3. Бизнес-аналитики могут использовать Amazon QuickSight, Tableau
или Power BI для построения визуализаций для бизнес-пользователей или избирательно загружать данные в Amazon Redshift для создания витрины (mart)
данных. Наконец, аналитики данных могут потреблять их с использованием
Amazon SageMaker для целей МО.
Ни один инструмент не является универсальным. Для каждой задачи необходим
свой подходящий инструмент, а озера данных позволяют строить архитектуры
больших данных с широкими возможностями настройки, которые можно адаптировать для конкретных целей.
Тем не менее со временем пришло осознание, что у озер данных есть свои ограничения. Так как озера используют дешевые хранилища, компании стараются
хранить там как можно больше данных, пользуясь гибкостью открытого, прямого доступа к файлам. Из-за проблем с качеством данных и детализированным
управлением доступом озера быстро стали превращаться в «болота». Чтобы
решить проблемы с производительностью и качеством озер данных, организации обрабатывают небольшие подмножества данных из озера в нижележащем
едином хранилище данных, чтобы использовать их в BI-приложениях бизнесаналитики для принятия ключевых решений.
Двухсистемная архитектура с озером данных (data lake) и хранилищем данных
(data warehouse) требует непрерывной инженерии данных для их поддержания
Проектирование архитектур Big Data
477
и обработки между двумя системами. На каждом этапе обработки появляется
риск сбоев, которые могут повлиять на качество данных. Кроме того, согласование данных между озером и хранилищем может быть и непростой, и затратной операцией. Пользователи сталкиваются с необходимостью платить за
хранение дважды — один раз за данные, хранящиеся в озере, а потом за данные,
реплицируемые в хранилище. Эти затраты прибавляются к текущим затратам
на непрерывную обработку данных.
Для решения проблем двухсистемной архитектуры появилась новая разновидность архитектуры, называемая озером-хранилищем данных (data lakehouse).
В следующем разделе эта архитектура рассматривается более подробно.
Архитектура озера-хранилища данных
(data lakehouse)
y
y
y
y
y
y
Архитектура озера-хранилища сформировалась как решение, заполняющее
пробел между традиционными озерами данных и хранилищами данных. Оно
сочетает сильные стороны обеих архитектур. Основной задачей при проектировании этой архитектуры был контроль над огромной емкостью озер данных для
поглощения и хранением огромных объемов данных в открытых форматах, что
необходимо для аналитики. При этом она также стремится обеспечить простоту
SQL-запросов и надежность, присущую хранилищам данных. Назовем ключевые
характеристики архитектуры озера-хранилища данных.
y Хранение данных в открытых форматах: это упрощает взаимодействия
и увеличивает гибкость при обработке данных и аналитике.
y Разделение хранения и вычислений: это делает возможным независимое
масштабирование и оптимизацию каждой подсистемы, что приводит к повышению эффективности и производительности.
y Транзакционные гарантии: обеспечивая целостность данных, архитектура
озера-хранилища данных гарантирует (по аналогии с гарантиями традиционных систем баз данных) поддержку надежного конкурентного доступа
и модификаций.
y Поддержка разнообразных потребностей использования данных: архитектура включает разные методы аналитики и обработки данных, от пакетных
до потоковых в реальном времени.
Безопасность
и рациональное управление: архитектура гарантирует конy
троль над доступом к данным и соответствие нормативным требованиям
к конфиденциальности данных.
y Унифицированная платформа: архитектура предоставляет унифицированную платформу для различных операций с данными, от процессов ETL
и МО до бизнес-аналитики и построения отчетов, снимая необходимость
в использовании разных систем.
478
Глава 12. Инженерия данных для архитектур решений
y
y Улучшенная производительность запросов: за счет применения таких мето-
y
y
дов, как индексирование, кэширование и группировка данных, повышается
производительность запросов, вследствие чего архитектура лучше подходит
для сложных аналитических рабочих нагрузок.
y Экономичная масштабируемость: это позволяет выдержать баланс между
потребностью в производительности и бюджетными ограничениями, особенно
важный для расширения томов данных.
y Гибкое управление данными: архитектура поддерживает гибкие практики
управления данными, возможность адаптироваться к эволюционирующим
схемам данных и структурам, вследствие чего она идеально подходит для
адаптивных и развивающихся бизнес-сред.
Архитектура озера-хранилища стала значительным достижением в управлении
данными. Она предоставляет всесторонний, масштабируемый и эффективный
подход к работе с обширными, разнообразными датасетами, при этом обеспечивая
целостность, безопасность данных и удобный доступ к ним.
На рис. 12.8 представлен пример архитектуры озера-хранилища, использующей Redshift Spectrum для совместного доступа к данным. Amazon Redshift
Spectrum предоставляет возможность запрашивать данные из озера без перемещения их в хранилище. Представим, что вы уже используете Amazon Redshift
для создания хранилищ данных. В таком случае вам не нужно выгружать
все данные в кластер Amazon Redshift и вы можете использовать Spectrum
для запроса данных непосредственно из озера Amazon S3 и объединения их
с данными из хранилища.
Каталог данных
Кредитные
истории
AWS Glue
используется для
хранения метаданных
Чтение данных
кредитных историй
AWS Glue
Совместное использование данных
Если сотруднику отдела скоринга
понадобится доступ к данным по займам,
вы можете предоставить ему схему
данных в режиме read-only
Данные поглощаются
из локального EDW
в Amazon S3 через S3 API
Кредитные
истории
Локальные
базы данных
Amazon S3
Займы
Чтение данных
по займам
Займы
Владение данными
Данные кредитных историй
и займов поддерживаются
независимо каждым отделом
Доступ к данным
Авторизованные пользователи получают
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)
Главное отличие сетки данных от озера-хранилища заключается в том, что данные
в ней намеренно остаются распределенными, не так, как в озере, где несколько
предметных областей объединяются под централизованным управлением. Сетка
данных предоставляет схему, которая позволяет крупной организации связать
несколько внутренних озер / озер-хранилищ и упростить совместное использование данных с партнерами, научной средой и даже конкурентами.
y
y
Сетка данных представляет собой значительный сдвиг парадигмы как в архитектурных, так и в организационных подходах к управлению обширными
аналитическими датасетами. Архитектура сетки данных основана на четырех
фундаментальных принципах.
y Децентрализация владения и архитектуры на основе предметной области:
этот принцип выводит на первый план децентрализацию владения данными
и архитектурных решений и передачу их конкретным областям бизнеса.
Отдельные бизнес-области принимают ответственность за свои данные, что
способствует созданию более эффективных и специализированных решений.
y Обращение с данными как с продуктом: это означает, что при обслуживании, улучшении и представлении данных учитываются интересы конечного
480
Глава 12. Инженерия данных для архитектур решений
y
y
пользователя. Представление о данных как об обычном ресурсе преобразуется
в представление о ценном активе, который приносит практическую пользу
и решает задачи конечного пользователя.
y Федеративное управление данными с централизованным контролем
аудита: этот принцип помогает выдержать баланс между децентрализованным управлением данными и потребностью в общем контроле. Он
позволяет конкретным бизнес-областям распоряжаться своими данными
при сохранении централизованного контроля в целях аудита и обеспечения комплаенса.
y Общий доступ: этот принцип, обеспечивающий доступность данных и возможность их использования в границах организации, направлен на создание
общего фреймворка, позволяющего легко и эффективно потреблять данные.
Архитектура сетки данных поощряет адаптивность, управляемую данными,
и поддерживает контроль данных с привязкой к бизнес-областям за счет политики облегченной централизации. Сетка данных обеспечивает грамотное
владение данными благодаря изоляции ресурсов данных с четким разделением
ответственности.
Основная концепция сетки данных — представление доменов данных как узлов
в озере данных. Производитель данных заносит один или несколько продуктов
данных в центральный каталог под учетной записью сетки данных. При этом
совместное использование продуктов данных подчиняется федеративному
контролю, что способствует прозрачности метаданных и аудируемости. Потребитель данных проводит поиск в каталоге и получает доступ к продукту
данных. Совместный доступ к ресурсу организуется через паттерн сетки данных.
На рис. 12.9 изображена архитектура сетки данных в облаке AWS.
Учетная запись озера данных
Регистрация местоположения данных
Учетная запись федеративного контроля
Необработанные Доверенные Очищенные
Роль IAM
Преобразования
и обогащение
Каталог
данных
Теги
столбцов
таблицы
Создание локальной базы данных
Роль IAM
Создание ссылки на ресурс в таблице
Предоставление роли бота Glue разрешений для изменения/
обновления БД/таблиц через LF
Запуск бота для существующей таблицы каталога (таблица ссылок
на ресурсы)
Каталог
Создание БД
данных
и таблицы
Теги
столбцов
таблицы
Изменение метаданных
из озера данных обеспечивает
согласование каталога
с изменениями схемы
и/или разделов
Учетная запись потребителя
Amazon
Athena
AWS
Glue
Amazon
Redshift
Каталог данных
Теги
столбцов
таблицы
Создание БД / ссылки на ресурс
Предоставление роли LAM (потребителя)
разрешения SELECT через LF
Потребитель отправляет запрос
к учетной записи производителя
Рис. 12.9. Архитектура сетки данных на облачной платформе AWS
Проектирование архитектур Big Data
481
y
y
y
y
Основные компоненты сетки данных на приведенной диаграмме:
y центральная учетная запись AWS, в которой регистрируются продукты
данных, включая базы данных, таблицы, столбцы и строки;
y теги управления доступом и политики доступа к тегам находятся под централизованным управлением;
y хранение разрешений данных, реализующих совместное использование
с потребителем. Разрешения могут быть как прямыми, так и основанными
на тегах;
y применение политик безопасности и управления к учетным записям производителя и потребителя, а также опубликованным ими продуктам данных.
Архитектура сетки данных позволяет ускорить независимую поставку озер-хранилищ для разных бизнес-областей. Сетка данных повышает безопасность данных и комплаенс в предметных областях и делает возможным самостоятельное
создание, обнаружение и подписку на продукты данных, позволяя потребителям
беспрепятственно получать доступ к ним.
В настоящее время растет потребность в быстром получении аналитических
данных и оперативном реагировании на потребности клиентов, вследствие чего
аналитика потоковых данных становится важной для любого бизнеса. В следующем разделе архитектура аналитики потоковых данных рассматривается
более подробно.
Архитектура потоковых данных
Потоковые данные — стремительно расширяющийся в последнее время сегмент. Они требуют поглощения и быстрой обработки в реальном времени, при
этом они поступают из разнообразных источников. Такими источниками могут
быть видео и аудио, журналы приложений, данные посещений сайтов и теле
метрии IoT. Цель во всех случаях одна — быстро получить аналитические выводы
для бизнеса. Типичные сценарии использования потоковых данных строятся
по одной схеме.
1. Генерирование данных: источники постоянно производят данные.
2. Поглощение: данные проходят через стадию поглощения на уровень хранения потоковых данных.
3. Хранение потоковых данных: на этом уровне входные данные надежно сохраняются и становятся доступными для обработки в реальном времени.
4. Потоковая обработка: на этой стадии происходит обработка данных, находящихся на уровне хранения. Это могут быть фильтрация, агрегирование
или анализ передаваемых данных.
5. Вывод данных: обработанные данные передаются в указанное место назначения, которым может быть база данных, озеро данных или другое решение,
для дальнейшего использования или долгосрочного хранения.
482
Глава 12. Инженерия данных для архитектур решений
Такая схема гарантирует, что данные будут не только сгенерированы, но и свое
временно обработаны, что способствует более быстрому принятию решений
и получению бизнес-инсайтов.
Архитектура потоковых данных отличается от других тем, что необходимо обрабатывать непрерывный поток данных с очень высокой скоростью. Часто эти
данные являются полуструктурированными и требуют сложной обработки,
чтобы из них можно было извлечь полезную информацию. При проектировании
архитектур потоковых данных необходимо обеспечить быстрое масштабирование хранилища данных. Очень важно также идентифицировать закономерности
в данных в реальном времени (особенно для временнˆых рядов).
При проектировании следует уделять внимание производителю, генерирующему
поток данных (например, датчикам IoT), тому, как планируется хранить и обрабатывать данные с использованием средств обработки в реальном времени,
и, наконец, организации запросов к данным в реальном времени. На рис. 12.10
изображен пайплайн аналитики потоковых данных, использующий управляемый
сервис на платформе AWS.
AWS Lambda
Устройство IoT
(на ветроэлектростанции)
AWS IoT
Greengrass
Amazon Kinesis
Data Firehose
Amazon Simple
Storage Service
(Amazon S3)
Amazon Kinesis
Data Streams
Greengrass
Amazon Kinesis
Data Analytics
for SQL
Amazon Kinesis
Data Analytics
for Java Flink
Amazon
OpenSearch
Рис. 12.10. Аналитика потоковых данных для данных IoT
На диаграмме показано, как поглощается поток данных от ветроэлектростанции;
это нужно для анализа работоспособности и скорости ветряных двигателей. Важно управлять устройствами в реальном времени, чтобы избежать дорогостоящего
ремонта в случае, если скорость ветра превышает предельное значение двигателя.
Данные от ветряного двигателя поглощаются в 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
y
y
Выбор между архитектурой озера данных, озера-хранилища и сетки данных
зависит от конкретных бизнес-требований, стратегии данных и технических
возможностей. Каждая архитектура обладает уникальными преимуществами
и лучше всего работает в определенных сценариях управления данными и аналитики. Чтобы вам было проще сделать правильный выбор, ниже показаны
преимущества, основные факторы и идеальные сценарии использования для
каждого типа архитектуры.
y Озеро данных предназначено прежде всего для хранения больших объемов
необработанных данных в исходном формате.
Преимущества: обеспечивает высокую масштабируемость и гибкость при
работе с разными типами данных. Экономичное решение для хранения
больших объемов данных, может использоваться как центральный репозиторий для всех данных организации.
Недостатки: без должного контроля озера данных могут стать неуправляе
мыми (превратиться в «болота данных»). Обеспечение качества данных
и доступности требует тщательного управления.
Сценарии использования: хорошо подходит для аналитики Big Data, МО
и сценариев, требующих хранения и анализа больших объемов разнородных данных при низких затратах — включая структурированные, полуструктурированные и неструктурированные данные — без обязательного
наличия заранее определенной схемы в точке входа данных.
y Озеро-хранилище данных сочетает элементы озера данных и хранилища
данных.
Преимущества: экономичное масштабирование озер данных в сочетании
с мощной поддержкой схем и оптимизацией производительности, присущих хранилищам данных. Предоставляет унифицированную платформу
для всех типов обработки данных и аналитики, сокращая необходимость
484
Глава 12. Инженерия данных для архитектур решений
y
y
y
y
y
y
в обособленных базах данных. Также поддерживает транзакции ACID
и схемы, повышая надежность и качество данных.
Недостатки: реализация этой архитектуры может оказаться сложной, так
как она требует интеграции разных компонентов и обеспечения согласованности и надежности между разными рабочими нагрузками.
Сценарии использования: лучше всего подходит для организаций, требующих обработки больших данных и традиционной бизнес-аналитики
на одной платформе. Идеальна для сценариев, требующих аналитики
в реальном времени и отчетов на больших и разнородных датасетах.
Сетка
данных: упор на децентрализацию архитектуры данных и владение ими.
y
Данные рассматриваются как продукт, а команды разных бизнес-областей
владеют своими данными и предоставляют их в виде продуктов остальным
подразделениям организации.
Преимущества: более динамичное и гибкое управление данными и аналитический подход. Также способствует демократизации данных, что
позволяет быстрее принимать решения и применять инновации в бизнес-областях.
Недостатки: требует изменения подхода к управлению и совместному
использованию данных. Необходимы продуманное управление и стандартизация между бизнес-областями, чтобы обеспечить совместимость
и качество данных.
Сценарии использования: подходит для больших организаций с несколькими независимыми командами или отделами, где разные бизнес-области
производят и потребляют данные.
Ключевые факторы для принятия решения:
y организационная структура: оцените, является ваша организация централизованной или децентрализованной. Сетка данных лучше подходит для
второго типа;
y объем и разнообразие данных: озера данных идеально подходят для больших
разнообразных наборов данных, тогда как озера-хранилища предоставляют
более структурированную среду для таких данных;
y аналитические потребности: озеро-хранилище может быть оптимальным
вариантом, если вам нужна аналитика в реальном времени в сочетании с обработкой больших данных;
y управление и комплаенс: оцените потребности в управлении данными, качестве и нормативном соответствии. Архитектура озера-хранилища обычно
обеспечивает более мощные механизмы управления;
y техническая квалификация: реализация и управление сеткой данных или озером-хранилищем требует специфических технических навыков или ресурсов.
В конечном счете выбор определяется соответствием архитектуры бизнес-целям,
техническим возможностям и стратегии данных. У каждой архитектуры есть свои
сильные стороны, и лучшим вариантом может даже оказаться гибридный подход.
485
Лучшие практики архитектуры Big Data
Лучшие практики архитектуры Big Data
В предыдущих разделах были рассмотрены технологии и архитектурные паттерны больших данных. Для изучения лучших практик давайте рассмотрим
рис. 12.11, где в качестве референса показана диаграмма архитектуры озера
данных с разными уровнями.
Корпоративный датацентр
РСУБД
Облако AWS
AWS Direct
Connect
Поглощение
данных
Озеро-хранилище
Каталог данных
и управление доступом
Amazon EMR
AWS DMS
Amazon SageMaker
ИИ/МО
На базе файлов
Пакетная
обработка ETL
AWS Data Sync
Amazon S3
Обработанные
данные
Необработанные
данные
AWS Transfer
for SFTP
Amazon
Redshift
Amazon
QuickSight
AWS Glue
Приложение
Amazon Athena
Ad hoc запросы
Amazon Kinesis
Data Firehose
Шифрование данных, управление доступом, мониторинг, аудит
KMS
IAM
CloudWatch
CloudTrail
SNS
Macie
Рис. 12.11. Архитектура озера данных как референс
y
y
y
На диаграмме изображен сквозной пайплайн данных в архитектуре озера данных с использованием облачной платформы AWS. Он включает следующие
компоненты.
y AWS Direct Connect настраивает скоростное сетевое подключение между
локальным центром данных и AWS для миграции данных. Если вы работаете
с большими объемами архивных данных, лучше воспользоваться семейством
AWS Snow для выведения их в офлайн.
y Уровень поглощения данных с разными компонентами поглощает потоковые данные при помощи Amazon Kinesis, реляционные данные при
помощи AWS DMS (Data Migration Service), безопасно передает файлы
при помощи AWS Transfer for SFTP (Secure Shell File Transfer Protocol),
обновляет файлы данных между облачными и локальными системами при
помощи AWS DataSync.
y Централизованное хранилище для всех данных с использованием Amazon S3
содержит несколько уровней для хранения необработанных, обработанных
и архивных данных.
486
Глава 12. Инженерия данных для архитектур решений
y
y Amazon Redshift — облачно-ориентированное решение хранилищ данных
с Redshift Spectrum для поддержки архитектуры озера-хранилища.
y
y Функциональность ситуативных (ad hoc) запросов с использованием Amazon
y
y
y
y
Athena.
y Быстрый пайплайн ETL на базе Spark с использованием AWS Glue.
y Amazon EMR повторно использует существующие скрипты Hadoop и другие
фреймворки Apache Hadoop.
y Amazon Lake Formation для подробной каталогизации данных и детализированного управления доступом на уровне озер данных.
y Расширение ИИ/МО с Amazon SageMaker.
Среди других компонентов можно упомянуть Amazon KMS (Key Management
Service) для шифрования данных, Amazon IAM (Identity and Access Management)
для управления доступом, Amazon Macie для выявления персональной информации с целью соблюдения таких нормативов, как PCI DSS (Payment Card Industry
Data Security Standard), CloudWatch для мониторинга операций и CloudTrail
для аудита операций в озере данных.
y
y
Для проверки архитектуры больших данных используются следующие критерии.
y Безопасность:
классификация данных и определение соответствующих политик защиты
данных с использованием управления доступом на базе ресурсов;
реализация надежной основы для идентификации с использованием
пользовательских разрешений и системы единого входа (SSO);
включение трассировки среды и данных для целей аудита;
обеспечение безопасности на всех уровнях, защита данных при передаче
и при хранении с применением SSL и шифрованием на всех уровнях;
защита данных от посторонних — например, блокировка доступа для записи к базам данных в продакшен-среде.
y Надежность:
поддержание гигиены данных с использованием автоматического профилирования на базе каталогизации данных;
кправление жизненным циклом активов данных, переходами и сроком
жизни с использованием распределения данных между хранилищем
и озером данных;
сохранение информации о происхождении данных путем поддержания
истории перемещения данных по каталогу;
проектирование устойчивости в пайплайнах аналитики и отслеживание
системных SLA с автоматизированным восстановлением сбоев заданий
ETL.
Итоги
487
y
y Производительность:
профилирование данных для повышения производительности при про-
y
y
верке данных для формирования уровня очистки;
непрерывная оптимизация хранения данных — например, сжатие данных
в формате Parquet, секционирование данных, оптимизация размеров
файлов и т. д.
y Оптимизация затрат:
принятие модели потребления и определение типа требуемых запросов —
ad hoc или быстрые;
удаление неиспользуемых данные; определение правил хранения и удаление или архивирование данных с истекшим сроком хранения;
отделение вычислений от хранения в решениях на базе озер данных;
реализация эффективной миграции за счет применения разных стратегий
миграции для разных источников и объемов данных;
использование управляемых сервисов и сервисов уровня приложения
для сокращения затрат владения.
y Операционное совершенство:
реализация стратегии «операции как код» при помощи таких инструментов, как 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. Архитектура машинного обучения
y
y
y
y
y
y
y
y
В этой главе будут рассмотрены следующие темы.
y Что такое машинное обучение?
y Наука о данных (data science) и машинное обучение.
y Машинное обучение в облаке.
y Создание архитектуры машинного обучения.
y Принципы проектирования для архитектуры машинного обучения.
y MLOps.
y Глубокое обучение.
y Обработка естественного языка (NLP).
К концу главы вы будете понимать архитектуру и узнаете о разных моделях
и рабочих процессах МО. Вы поймете, как создается пайплайн модели МО посредством генерации признаков, обучения модели, инференса и оценки модели.
Что такое машинное обучение?
Машинное обучение улучшает взаимодействие с пользователем, повышает
эффективность бизнес-операций, ускоряет и повышает точность принятия
решений. С ростом вычислительных мощностей и объемов данных машинное
обучение переместилось с периферии, став основным отличительным качеством
бизнеса и организаций в различных отраслях. Сценарии использования МО —
персонализированные рекомендации продуктов и контента, автоматизация
контакт-центров, проверка виртуальной личности, интеллектуальная обработка
документов — применимы в большинстве отраслей. Также существуют сценарии,
специфичные для конкретных отраслей — например, клинические испытания
в фармакологии или контроль качества сборочных линий на производстве.
y
y
y
y
МО использует технологии для выявления новых тенденций и формирования
математических прогностических моделей на основе прошлых фактических
данных. МО может помочь с решением многих нетривиальных задач.
y Создание сложных правил: когда необходимо принимать решения, для которых невозможно прописать четкую логику в коде, например распознавание
человеческих эмоций в изображениях или речи.
y Анализ больших объемов данных: в случаях, когда объем информации слишком велик для эффективной обработки человеком. Например, хотя человек
может справиться с обнаружением спама, объем данных не позволяет быстро
решить эту задачу вручную.
y Динамическая адаптация: если информация, нужная для персонализации,
доступна только динамически, в режиме реального времени. Например,
индивидуальные рекомендаций товаров или персонализация веб-сайтов.
y Обработка потоковых данных: в ситуациях, требующих мгновенного анализа
больших данных для принятия решений, таких как обнаружение мошенничества или обработка естественного языка (NLP).
Что такое машинное обучение?
491
y
y
y
y
y
y
y
Люди составляют прогнозы данных, базируясь на результатах анализа и своем
опыте. При помощи МО можно обучить компьютер предоставлять рекомендации на основе доступных данных и получать прогнозы на основе новых данных.
Вот несколько распространенных сценариев использования МО в различных
отраслях.
y Прогнозное обслуживание: предсказание возможных сбоев компонентов
на основании данных датчиков. Этот метод обычно применяется при оценке
остаточного срока эксплуатации (RUL, Remaining Useful Life) автопарков,
производственного оборудования и датчиков IoT. Его основными преимуществами являются повышение времени полезной работы оборудования и значительная экономия средств. Это применение часто встречается
в автомобилестроении и производстве.
y Прогнозирование спроса: использование исторических данных для ускоренного и более точного определения ключевых метрик спроса, способствующее
принятию более точных бизнес-решений о производстве, ценообразовании,
управлении запасами и приобретении/пополнении. Основные преимущества — удовлетворение покупательского спроса, минимизация затрат на
поддержание запасов за счет сокращения излишков, а также сокращение
отходов. Этот сценарий часто встречается в таких отраслях, как финансовые
услуги, производство, розничная торговля и товары широкого потребления.
y Обнаружение попыток мошенничества: автоматизация распознавания возможных мошеннических действий и их пометка для дальнейшей проверки.
Основные преимущества — сокращение потерь от мошенничества и доверие
клиентов. Этот сценарий обычно реализуется в секторах финансовых услуг
и розничной торговли в интернете.
y Прогнозирование кредитных рисков: данный подход позволяет анализировать индивидуальные кредитные заявки для оценки вероятности погашения
кредита (так называемый кредитный дефолт). Преимущества связаны с выявлением потенциальных предвзятостей в оценке и обеспечением соответствия нормативным требованиям. Этот сценарий характерен для отрасли
финансовых услуг и розничной торговли в интернете.
y Извлечение данных и анализ документов: распознавание текста в рукописных и цифровых документах, извлечение информации для классификации
и целей принятия решений. Данный сценарий широко распространен в таких
секторах, как здравоохранение, финансовые и юридические услуги, механика,
электротехника и образование.
y Персонализированные рекомендации: создание индивидуальных рекомендаций на основании исторических данных. Такой подход часто используется
в секторах розничной торговли и образования.
y Прогнозирование оттока: оценка вероятности того, что клиенты прекратят
пользоваться услугами. Часто используется в таких отраслях, как розничная
торговля, образование и у поставщиков SaaS (Software as a Service).
492
Глава 13. Архитектура машинного обучения
Основная концепция машинного обучения заключается в предоставлении
алгоритму обучающего датасета для последующего прогнозирования на новых
данных. Например, передача исторических данных о тенденциях фондового
рынка МО-модели позволяет прогнозировать рыночные колебания на период
от шести месяцев до года.
При разработке систем МО важно тщательно продумать синхронизацию данных
с кодом. Данные и алгоритм должны быть хорошо организованы и развиваться
под контролем для достижения общей цели — создания надежной и масштабируемой системы МО.
Данные, используемые для обучения, тестирования и принятия решений
в механизме логического вывода (инференса) МО-системы, изменяются со
временем, так как поступают из разных мест. Код также должен изменяться
вместе с данными. Без систематизации неизбежны расхождения между кодом
и изменившимися данными. Несоответствие создаст проблемы, когда система
МО начнет использоваться для реальных задач. Оно также может затруднить
развертывание и привести к тому, что получаемые результаты будет трудно
понять, отследить или повторить.
Существуют разные типы МО; в следующем разделе мы рассмотрим их более
подробно.
Типы машинного обучения
МО помогает компьютерам получать новую информацию без программирования
всего, что для этого нужно. Фактически вы объясняете компьютеру, как учиться
на имеющемся опыте. Представьте, что вы обучаете собаку какому-нибудь трюку: вы показываете, что нужно сделать, собака учится, а потом его выполняет!
С МО компьютеры могут учиться на данных, а затем использовать обучение для
принятия решений. Рассмотрим виды машинного обучения.
Обучение с учителем
При обучении с учителем (supervised learning) алгоритму предоставляется набор
обучающих примеров, в которых данные и целевые решения известны. После
этого он предсказывает целевое значение для новых наборов данных с теми же
атрибутами. При таком типе алгоритм обучается на датасете, в котором входные
данные связаны с правильным ответом (или целью). На этих примерах алгоритм
учится связывать входные данные с правильными результатами.
Такой тип обучения часто используется для задач, требующих классификации
объектов по категориям или предсказания чисел, как в задачах классификации
и регрессии. Например, он может применяться для разделения сообщений
электронной почты на спам и важные сообщения или прогнозирования цены
недвижимости на основании ее характеристик.
Что такое машинное обучение?
493
Обучение без учителя
При обучении без учителя (unsupervised learning) алгоритм получает огромный
объем данных и пытается выявить в них закономерности и отношения. После
этого он может делать выводы на основании наборов данных.
Обучение без учителя не требует участия человека — например, классификация
документов на основании их содержимого может происходить автоматически.
Таким образом решается проблема того, что правильный результат может быть
недоступен для обучающего набора, и алгоритм должен обнаружить закономерности в данных посредством группировки.
При обучении без учителя модель обучается на неразмеченных данных. Алгоритм
самостоятельно выявляет закономерности, структуры и отношения в данных
без рекомендаций или примеров, которым нужно следовать. Такой тип обу
чения часто применяется в задачах группировки, сокращения размерности
и оценки плотности. Новостным агентствам или юридическим фирмам часто
приходится иметь дело с большими объемами данных. Применяя обучение без
учителя, они могут автоматизировать классификацию документов, эффективно
управлять цифровыми репозиториями и совершенствовать процессы получения
информации — например, рекомендуя похожие статьи или дела читателям или
исследователям.
Обучение с частичным привлечением учителя
В варианте обучения с частичным привлечением учителя (semi-supervised
learning) объединяются элементы двух предыдущих типов. Здесь используется
небольшой объем размеченных данных и значительный объем неразмеченных
для повышения производительности модели. Такая модель особенно полезна,
когда получение размеченных данных либо обходится слишком дорого, либо
требует слишком длительного времени. Она часто используется в сценариях, где
размеченных данных мало, а неразмеченных, наоборот, очень много. Например,
обучение с частичным привлечением учителя может быть очень востребованным в биомедицине. Разметка медицинских снимков требует большого времени
и ресурсов, вследствие чего такой тип обучения становится оптимальным вариантом. Модели могут изначально обучаться на небольшом наборе размеченных
снимков, после чего настраиваться на более обширном наборе неразмеченных,
что обеспечит максимальную пользу при минимальных затратах и ресурсах.
Обучение с подкреплением
Этот тип обучения (reinforcement learning) подразумевает обучение агентов
(компьютерных программ) для принятия последовательных решений в заданной
среде. Цель в том, чтобы агент научился выполнять наилучшие действия для
получения со временем максимально возможной совокупной награды. В ходе
494
Глава 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. Рабочий процесс МО
y
Как показано на диаграмме, рабочий процесс МО включает следующие этапы.
y Предварительная обработка: на этом этапе специалист по data science проводит предварительную обработку данных и делит их на три набора: обучающий
(70 % данных), проверочный, или валидационный (10 % данных), и тестовый
(20 %). На первом модель обучается, накапливает информацию и учится давать правильные предсказания. По завершении обучения модель применяется
к отдельному проверочному датасету для оценки ее эффективности и способностей к обобщению. После готовности модели ее можно протестировать на
тестовом наборе. Признаки являются независимыми атрибутами датасета,
которые могут влиять (или не влиять) на результат. Генерация подразумевает
Data science и машинное обучение
497
y
y
y
поиск правильных признаков, которые помогут обеспечить точность модели.
Метка — целевой результат, зависящий от выбора признаков. Сокращение
размерности может применяться для выбора правильных признаков, чтобы
отфильтровать и извлечь из данных самые содержательные.
y Обучение: на этом этапе для конкретного бизнес-сценария выбирается
подходящий алгоритм МО и данные. Это самый важный этап рабочего
процесса МО: на нем модель обучается на соответствующем датасете. Для
повышения точности модели необходимо экспериментировать с разными
гиперпараметрами и проводить выбор моделей. Гиперпараметры — настройки конфигурации, используемые для управления процессом обучения
в алгоритмах МО.
y Оценка: после того как модель МО пройдет обучение, необходимо оценить
ее точность (accuracy) на известном датасете. Для оценки модели используется проверочный датасет, зарезервированный на этапе предварительной
обработки. По результатам оценки проводится дополнительная настройка
модели, если необходимо пересмотреть точность прогнозирования ввиду
исключений, определенных проверочными данными.
y Прогнозирование: также называется «логическим выводом» (inference). На
этом этапе модель применяется на практике и начинает делать прогнозы. Прогнозирование может происходить в реальном времени или в пакетном режиме.
Генеративный ИИ привел к сдвигу парадигмы в области МО и ИИ. В его основе лежат фундаментальные модели (ФМ) — такие, как GPT-4, — прошедшие
обучение на огромных датасетах в масштабе интернета и переопределившие
традиционные нормы разметки данных и настройки моделей. Эта революционная технология позволяет организациям оптимизировать фундаментальные
модели, значительно сокращая привычные объемы ручных операций и времени
для подготовки данных.
Тем не менее важно понимать, что генеративный ИИ не панацея, поскольку эта
технология не проектировалась для решения всех проблем ИИ и МО. Кроме
того, разработка ФМ требует значительных ресурсов, включая вычислительную
мощность и доступ к обширным наборам данных. Как следствие, многие компании выбирают использование ФМ, предоставленных известными сторонними
поставщиками: OpenAI, Google, Meta и Anthropic, которые были первопроходцами в разработке этих моделей.
Но и это еще не все. Обучение специализированной модели остается привлекательным вариантом — особенно там, где необходимы конкретные, специализированные решения. Хотя генеративный ИИ представляет новаторский подход
к решению задач, стратегическое решение о его принятии должно соответствовать
уникальным целям, ресурсам и ограничениям организации. Вы больше узнаете
о генеративном ИИ в главе 14 «Архитектура генеративного ИИ».
Как и в случае с входными данными, у модели МО часто возникают проблемы
переобучения (overfitting) или недостаточного обучения (underfitting), которые
498
Глава 13. Архитектура машинного обучения
необходимо учитывать для получения правильного результата. В следующем
разделе эта тема рассматривается более подробно.
Оценка моделей МО — переобучение
и недостаточное обучение
При переобучении модель нуждается в обобщении; иначе говоря, она должна
показывать хорошие результаты не только с данными, на которых она обучалась
(обучающий набор), но и на новых, не встречавшихся ранее данных (тестовый
или проверочный набор).
Если модель переобучена, она фактически запомнила обучающие данные и сохранила шум вместе со скрытой закономерностью, что приводит к низкой эффективности на новых данных. Если модель демонстрирует высокие метрики
эффективности на обучающих данных, но существенно более низкие метрики
на тестовых данных, это является признаком переобучения.
Обычно переобучение указывает на то, что модель обладает излишней гибкостью в отношении обучающих данных, которая позволяет ей запоминать
данные, включая шум. Переобучение ведет к высокой дисперсии, когда небольшие изменения обучающих данных приводят к значительным изменениям
результатов.
При недостаточном обучении модель не способна выявить важнейшие закономерности в обучающем наборе. Как правило, недостаточное обучение
указывает на то, что модель слишком проста или в ней не хватает независимых
переменных. Недостаточно обученная модель должна быть более гибкой для
моделирования реальных закономерностей; недостаточное обучение указывает
на высокое смещение, обусловленное систематической нехваткой подгонки
модели в определенной области.
Диаграммы на рис. 13.2 наглядно демонстрируют различия между недостаточным
обучением и переобучением относительно хорошо обученной модели.
Х2
Х2
Недостаточное
обучение (высокое
смещение)
Х1
Х2
Хороший
компромисс
Х1
Переобучение
(высокая
дисперсия)
Рис. 13.2. Недостаточное обучение и переобучение модели МО
Х1
Data science и машинное обучение
499
Модель МО классифицирует две категории точек данных, обозначенных на
диаграммах кружками и крестиками. Модель МО пытается определить, купит
клиент заданный товар или нет. На иллюстрации изображены прогнозы трех
разных моделей МО. Модель с переобучением (справа) проходит при обучении
все «круглые» точки данных, но не может обобщить алгоритм для реальных
данных за пределами обучающего набора. С другой стороны, модель с недостаточным обучением (слева) пропускает несколько точек данных, ее точность
необходимо повысить. Хорошая модель (в середине) обычно предоставляет
четкие прогнозы точек данных. Создание хорошей модели МО сродни созданию
произведения искусства; возможно, вам удастся добиться такого результата при
помощи донастройки модели.
Популярные алгоритмы машинного обучения
Популярность алгоритма часто зависит от его применимости и эффективности
в разных сценариях использования, простоты понимания и реализации, а также
его способности к масштабированию и адаптации к разным типам данных. Рассмотрим некоторые популярные алгоритмы МО.
Линейная регрессия
Линейная регрессия пытается понять, в какой степени один фактор (скажем,
X) способен прогнозировать другой фактор (Y), выявляя линейные отношения
между ними. Представьте, что вы пришли на рынок. Изучая цены на тыквы, вы
замечаете, что с ростом размера тыквы также растет ее цена. Линейная регрессия
словно пытается провести прямую линию между всеми ценами на тыквы так,
чтобы она проходила как можно ближе ко всем точкам.
Линейная регрессия играет важнейшую роль в секторе недвижимости. Например,
если компания хочет спрогнозировать цену продажи дома, она проверяет такие
признаки, как количество комнат в нем, его местоположение и дату постройки
(возраст). Если дома с большим количеством комнат в прошлом обычно продавались по более высокой цене, модель прогнозирует более высокую цену на
дома с большим количеством комнат. Принцип тот же, как для прогнозирования
цены тыквы в зависимости от размера.
Логистическая регрессия
Логистическая регрессия прогнозирует вероятность некоторого исхода на уровне
ответов «да» или «нет». Представьте, что вы пытаетесь предсказать, станет ли
книга бестселлером. Логистическая регрессия проверяет такие признаки, как
количество страниц, популярность автора и жанр, и предсказывает вероятность
(в интервале от 0 до 1) того, что книга станет бестселлером.
В здравоохранении логистическая регрессия может предсказать вероятность
некоторого заболевания у пациента на основании симптомов и результатов
500
Глава 13. Архитектура машинного обучения
анализов. Например, на основании таких факторов, как возраст, кровяное
давление и уровень холестерина, она может предсказать вероятность наличия
сердечных заболеваний. При высокой вероятности врачи могут провести дополнительные анализы, обеспечивая раннее снижение потенциальных рисков
для здоровья.
Деревья принятия решений
Деревья принятия решений помогают принимать серии решений путем ответа
на вопросы. Представим, что вам нужно выбрать подходящую одежду. Дерево
принятия решения может задать вопрос: «На улице идет дождь?» Если ответ
«да», оно может предложить дождевик. В случае ответа «нет» может быть задан
другой вопрос: «На улице жарко?» — и будет рекомендована соответствующая
одежда. Так вы будете перебирать варианты, пока не будет найден лучший из них.
Дерево принятия решений также может предсказать, купит ли клиент тот или
иной товар. Например, оно может спросить: «Покупал ли клиент что-нибудь
за последний месяц?» Если ответ «да», клиент с большой вероятностью может
сделать новую покупку в ближайшем будущем. В случае ответа «нет» дерево
может учесть другие факторы (например, недавние посещения сайтов или клики
рекламных объявлений) для прогнозирования покупательского поведения, помогая продавцам предоставить клиенту подходящую рекламу и предложения.
Случайный лес
Как подсказывает название, модель случайного леса работает с лесом, в котором
каждое дерево является деревом принятия решений, голосующим за результат.
Каждому дереву выделяется случайное подмножество данных, и оно старается
принять лучшее решение. Затем все деревья «голосуют», и на основании результатов выбирается окончательный ответ. Такой подход часто обеспечивает
более точные и стабильные прогнозы, чем отдельное дерево принятия решений.
В финансах модель случайного леса могут использоваться для решения о том,
одобрить или отклонить заявку на кредит. Деревья учитывают, например, такие
параметры, как кредитный рейтинг, доход и текущая задолженность клиента.
Окончательное решение, принимаемое большинством голосов всех деревьев,
получается более точным и надежным, чем с одной моделью; таким образом
сокращается риск одобрения кредитов неблагонадежным заемщикам.
Модель K ближайших соседей (k-NN)
Использование модели k ближайших соседей (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», помогая точно распознавать
рукописные цифры.
Нейронные сети
Нейронная сеть (или нейросеть) работает как мини-мозг внутри компьютера,
который учится на множестве примеров для принятия решений. Когда вы начинаете кататься на велосипеде, вы часто падаете, но со временем учитесь держать равновесие и крутить педали, понимая, что пошло не так в предыдущих
попытках. Нейросети учатся аналогично — исправляя прошлые ошибки, чтобы
принять лучшие решения в следующий раз.
Например, платформы социальных сетей используют нейросети для идентификации и отметки людей на фотографиях. В процессе обучения сеть анализирует
множество изображений людей и замечает такие признаки, как, например, форма
носа и цвет глаз. При отправке новой фотографии эти признаки сравниваются
с накопленной информацией, и нейросеть делает предположение относительно
того, кто на ней изображен.
Кластеризация методом k-средних
Кластеризация методом k-средних используется для группировки похожих точек
данных. Представьте, что вы устраиваете большую вечеринку и хотите объединить
друзей с похожими интересами в группы (кластеры), чтобы они не скучали. Вы
пробуете разные способы группировки, пытаясь добиться того, чтобы участники
групп были как можно ближе друг к другу и все хорошо провели время.
502
Глава 13. Архитектура машинного обучения
Популярное применение кластеризации методом k-средних — сегментация
клиентов для стратегий маркетинга. Компании могут применять кластеризацию
методом k-средних для группировки клиентов в зависимости от их покупательского поведения. Например, в одном кластере могут быть собраны клиенты,
которые покупают часто, но тратят мало, а в другом — те, что покупают редко,
но совершают большие покупки. На разные группы могут быть направлены
разные стратегии маркетинга для максимизации продаж.
XGBoost
XGBoost учится на прошлых ошибках и становится умнее с каждым решением.
Если вы решаете математические задачи и совершаете ошибку в одной из них,
XGBoost оценивает, понимает, что пошло не так, и запоминает ошибку, чтобы
в следующий раз избежать ее в похожей задаче.
В кредитной отрасли XGBoost широко применяется для прогнозирования
рисков невозврата кредитов. Многие факторы — доход, возраст, кредитная
история клиента — используются для прогнозирования невозврата. Если для
потенциального заемщика высока вероятность невозврата, его заявку могут
отклонить, чтобы свести к минимуму риск для банка.
Рассмотренные алгоритмы лежат в основе многих проектов МО. Они выбираются на основании поставленной задачи и типов обрабатываемых данных (текст,
графика, числа). Некоторые из алгоритмов — например, нейросети — требуют
больших вычислительных ресурсов и данных, тогда как другие (например,
деревья принятия решений или модель k ближайших соседей) могут быть применимы даже с небольшими датасетами.
Наше знакомство с МО продолжается. В следующем разделе будут рассмотрены
популярные инструменты и фреймворки МО.
Популярные инструменты и фреймворки
машинного обучения
МО реализуется при помощи различных инструментов и фреймворков, предназначенных для разных этапов разработки моделей МО — начиная с обработки
данных и проектирования алгоритмов и заканчивая обучением и развертыванием моделей.
y
Ниже представлены некоторые популярные инструменты для подготовки
и анализа данных.
y NumPy: основная библиотека Python для научных вычислений. Библиотека
NumPy (Numerical Python) содержит объекты многомерных массивов и набор
операций для работы с ними.
Массивом называется коллекция элементов данных одного типа, хранящихся
в смежных областях памяти.
Data science и машинное обучение
503
y
NumPy упрощает и повышает эффективность числовых и логических операций с большими наборами данных. Представьте торговую компанию, которая
хочет вычислить средний объем продаж для анализа эффективности и выбора будущей стратегии. У компании имеются данные ежедневных продаж,
хранящиеся в числовом формате. При помощи NumPy компания сможет
легко вычислить средние продажи за месяц; для этого она размещает данные
ежедневных продаж в массиве, суммирует и делит на количество дней.
y Pandas: эта библиотека предоставляет пользователям Python простые,
высокопроизводительные структуры данных и функции анализа данных.
В частности, Pandas предоставляет Series и DataFrames — две важнейшие
структуры данных для Python, построенные на базе NumPy.
Series представляет собой столбец, а DataFrame — многомерную таблицу,
состоящую из столбцов.
y
y
Функциональность Pandas упрощает очистку, анализ и визуализацию данных. Представьте, что продуктовый магазин хочет проанализировать свои
данные продаж, чтобы понять, какие продукты продаются лучше всего, а какие подолгу залеживаются на полках. У магазина имеется большой датасет
с информацией о каждой операции, включая название продукта, проданное
количество и цену. При помощи Pandas они смогут легко оперировать этими
данными, определить общие продажи по каждому продукту, отсортировать
их, а затем найти самые популярные позиции.
y Scikit-learn: эффективный и несложный инструмент прогнозного анализа
данных, работающий в сочетании с Pandas и NumPy. В Scikit-learn поддерживаются многие методы обучения с учителем и без учителя. Scikit-learn
широко применяется в МО, обычном и глубоком анализе данных и содержит
множество встроенных инструментов для выбора модели, оценки, импорта
и улучшения данных. Представьте, что банк хочет спрогнозировать, нарушит
ли новый клиент свои кредитные обязательства. У банка имеются исторические данные по предыдущим клиентам: возраст, зарплата, семейное положение, наличие невыплаченных кредитов в прошлом. При помощи Scikit-learn
банк может построить модель (например, дерево решений, логистическую
регрессию или другой подходящий алгоритм), которая обучается на этих
данных, а затем воспользоваться обученной моделью для прогнозирования
вероятности того, что новый клиент не вернет кредит.
Назовем популярные инструменты и фреймворки визуализации данных.
y Matplotlib: библиотека Python с широкой функциональностью для создания
статических, интерактивных и анимированных визуализаций. Помимо линейных графиков, точечных диаграмм, гистограмм, столбцовых, круговых
и 3D-диаграмм, Matplotlib предоставляет невероятно гибкую основу для
создания широчайшего спектра визуализаций. Этот инструмент позволяет
504
Глава 13. Архитектура машинного обучения
y
y
y
разработчикам и специалистам data science наглядно представлять свои
данные на разных типах диаграмм, что может быть очень полезно для понимания распределения и закономерностей данных, решения проблем при
отладке или визуализации отношений между данными. Представим, что
учитель хочет наглядно представить оценки учеников в классе, чтобы быстро
выделить общую успеваемость и статистические отклонения. При помощи
Matplotlib учитель может строить различные диаграммы (круговые, точечные,
гистограммы и т. д.) для представления распределения оценок в доступном
и легко воспринимаемом визуальном формате.
y Seaborn: библиотека визуализации статистических данных на базе Matplotlib,
предоставляющая высокоуровневый интерфейс для построения профессиональных графиков. Seaborn содержит встроенные темы оформления и цветовые палитры для быстрого создания привлекательных и содержательных
диаграмм. Seaborn особенно хорошо подходит для визуализации сложных
наборов данных с несколькими переменными благодаря макетам с несколькими диаграммами, а также функциональности наглядного представления
отношений между несколькими переменными. Представьте, что торговая
компания хочет понять поведение своих покупателей по ряду категорий
товаров за некоторый период времени. С Seaborn аналитики могут построить
тепловую карту для наглядного представления частоты покупки по разным
категориям продуктов за разные месяцы, что позволит быстро получить
представление о тенденциях и покупательских предпочтениях.
y Инструменты бизнес-аналитики (BI): такие инструменты бизнес-аналитики,
как Tableau, Microsoft Power BI, Amazon QuickSight и MicroStrategy, используются для преобразования необработанных данных в доступный формат.
Эти инструменты помогают наглядно представить, понять и принять решения
относительно имеющихся данных. В отличие от других упомянутых средств,
эти инструменты обладают графическим интерфейсом, где пользователи
могут перетаскивать элементы для анализа данных. Это особенно привлекательно для пользователей, не умеющих программировать. BI-инструменты
могут подключаться к разным источникам данных, формируя полезные
выводы в реальном времени. Они позволяют создавать и публиковать дашборды, представляющие собой интерактивные визуализации со встроенной
аналитикой. Например, сеть ресторанов хочет оптимизировать свою цепочку
поставок и меню на основании поведения клиентов и сезонных тенденций.
При помощи BI-инструмента компания может наглядно представить данные о продажах по разным измерениям (время, демографические признаки
клиентов, категории продуктов), выявить в них закономерности и получить
информацию для принятия решений.
Перечислим популярные инструменты и фреймворки для разработки и обучения моделей.
y TensorFlow: полнофункциональная платформа с открытым исходным кодом, предназначенная для решения целого спектра задач МО. TensorFlow
Data science и машинное обучение
505
y
y
y
поддерживает разные API для построения, обучения и развертывания ИИмоделей. Ключевая особенность TensorFlow — возможность построения
графов потоков данных. Такие графы показывают, как данные перемещаются
по разным этапам обработки (узлам). На графах каждый узел обозначает
математическую операцию, а соединения между узлами (ребра) представляют тензоры — многомерные массивы данных. TensorFlow предоставляет
инструменты разработчика для применения крупномасштабного МО, а также
обширную библиотеку для удобного изучения и разработки ИИ-моделей,
подходящую как новичкам, так и экспертам. Пример: учреждение здравоохранения решает использовать МО для прогнозирования заболеваний
на основании метрик пациента: возраста, генетических особенностей, веса
и вредных привычек. Такая организация может воспользоваться TensorFlow
для построения модели нейросети, которая учитывает все эти факторы и прогнозирует вероятность заболеваний.
y PyTorch: популярность этой библиотеки МО обусловлена ее гибкостью,
простотой использования и динамическим графом вычислений, особенно
полезным для глубокого обучения. Разработчики, исследователи и специа
листы по data science используют ее как в исследованиях, так и в рабочем
коде. Динамический граф вычислений позволяет изменять поведение сети
на ходу, а библиотека предоставляет богатый API для различных задач МО:
классификации, регрессии, обучения с подкреплением и т. д. Представим,
что интернет-магазин хочет создать чат-бота для улучшения взаимодействия
с пользователями. При помощи PyTorch можно разработать модель глубокого
обучения, которая понимает язык пользователей и дает полезные и точные
ответы на их вопросы в реальном времени.
y Keras: библиотека с открытым кодом, предоставляющая удобный API для
построения и тренировки моделей глубокого обучения. Может работать на
базе других популярных библиотек МО (таких, как TensorFlow), что делает
ее исключительно гибкой. В частности, популярность Keras обусловлена простотой и удобством использования в экспериментах. С Keras специалисты
data science и разработчики могут преобразовать свои идеи в практические
результаты с минимальной задержкой, что очень важно в инновационных
проектах. Возьмем компанию розничной торговли, которая рекомендует
товары покупателям на основании их прошлой истории покупок. Компания
может воспользоваться Keras для построения рекомендательной системы;
система анализирует закономерности покупок и предлагает товары, которые
будут приобретены с большей вероятностью.
y MLlib (Apache Spark): библиотека МО, являющая частью Apache Spark;
она спроектирована с учетом масштабирования для потребностей Big Data.
MLlib предоставляет различные алгоритмы МО, в том числе классификацию, регрессию, кластеризацию и коллаборативную фильтрацию, а также
инструменты для выбора и оценки модели. Она также включает API для
сохранения моделей с целью последующего использования. Библиотека
506
Глава 13. Архитектура машинного обучения
y
y
MLlib разработана для эффективного выполнения крупномасштабных задач МО. С учетом своих возможностей распределенных вычислений MLlib
может быстро обрабатывать огромные объемы данных, что особенно ценно
для сценариев, где критически важны анализ данных и обучение моделей
в больших масштабах. Более того, MLlib может использоваться с разными
источниками данных и форматами, предоставляя гибкость при работе с различными типами данных. Пример: финансовая компания, которая хочет выявлять мошеннические операции по кредитным картам в режиме реального
времени. При помощи MLlib аналитики могут обрабатывать огромные объемы данных о транзакциях для обучения моделей, выявляющих необычные
закономерности покупок или аномальные транзакции, свидетельствующие
о возможном мошенничестве. Такие модели делают возможным обнаружение
мошеннических действий и их блокировку в реальном времени.
Назовем популярные инструменты и фреймворки для развертывания моделей.
y Docker: платформа упрощает создание, развертывание и запуск приложений,
использующих контейнеры. Docker не является инструментом МО как таковым, но очень полезна для эффективного и последовательного развертывания
моделей и приложений МО. Docker позволяет разработчикам и специалистам
по data science упаковать приложение вместе со всеми его зависимостями
(библиотеками, инструментами и скриптами) в контейнер. Контейнер может
передаваться и запускаться в разных вычислительных средах; это означает,
что приложение будет одинаково работать независимо от того, где оно выполняется. Представьте, что команда разработчиков создает приложение
МО для прогнозирования биржевых котировок. В нее входят специалисты
по data science, которые используют различные инструменты и библиотеки
для создания моделей, и инженеры, которые строят приложение с применением разных технологий. При помощи Docker они могут создать связанный
рабочий процесс, в рамках которого все работают в согласованной среде; это
гарантирует, что модель и приложение будут одинаково вести себя во время
разработки, тестирования и развертывания, хотя они и разрабатывались
с применением разных инструментов.
y Flask: микрофреймворк, написанный на Python. Flask прост в изучении и использовании, вследствие чего хорошо подходит для начинающих, но в нем отсутствует дополнительная функциональность (например, проверка форм или
уровни абстракции баз данных), которую может обеспечить полностековый
фреймворк. С другой стороны, вследствие своей простоты и удобства Flask
пользуется популярностью для развертывания облегченных веб-приложений
и API, особенно в сообществе data science и МО. Пример сценария: специа
лист по data science разработал модель МО, предсказывающую, является ли
сообщение спамом. Эта модель может использоваться в веб-приложении, где
пользователь отправляет сообщение, а приложение определяет, является ли
оно спамом. При помощи Flask специалист по data science может создать простой веб-сервер, который получает текст сообщения, использует модель МО
Data science и машинное обучение
507
y
y
y
для определения того, является ли оно спамом, а затем возвращает результат
пользователю, — и все это через веб-интерфейс.
Перечислим популярные интегрированные среды разработки (IDE).
y Jupyter Notebook: веб-приложение с открытым исходным кодом; позволяет
создавать и распространять интерактивные документы. Эти документы могут
содержать живой код, формулы, визуализации и пояснительный текст, в результате чего они становятся гибкими инструментами для анализа данных,
научных исследований, а также в области образования. Jupyter поддерживает
разные языки (Python, R, Julia и т. д.) и широко применяется при очистке
данных, статистическом моделировании, МО и во многих других областях
благодаря своей интерактивной вычислительной среде. Jupyter занимает
важное место в data science, академических исследованиях и научных вычислениях, позволяя создавать воспроизводимые аналитические исследования
и наглядно представлять результаты с использованием визуализаций и сопроводительного текста. Допустим, биолог хочет проанализировать данные
о разных видах птиц и путях их миграции. Он может воспользоваться блокнотом Jupyter для написания кода Python, который загружает данные, наглядно отображает закономерности миграций и, возможно, даже использует
МО для предсказания будущих периодов или путей миграции на основании
исторических данных.
y RStudio: IDE с открытым исходным кодом для языка статистических вычислений и графики R, которая работает со стандартной версией R, а также
поддерживает облачные версии R. RStudio предоставляет мощную функциональность для разработки скриптов, визуализации данных и статистического
анализа, в полной мере раскрывая возможности языка R. Представьте, что
торговая компания хочет понять покупательское поведение своих клиентов.
При помощи RStudio аналитик данных может получить данные продаж,
применить статистический анализ и создать визуализации (точечные диаграммы, гистограммы, столбцовые диаграммы) для выявления тенденций,
популярных товаров и пиковых периодов покупок, возможно с применением
МО для прогнозирования будущих продаж.
y 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 c заранее обученными моделями, поддерживающими обнаружение ключевых фраз и анализ
тональности на разных языках.
Облако все чаще используется в качестве основной платформы для фундаментальных моделей генеративного ИИ, предлагая экономичную и масштабируемую
среду тестирования и развертывания этих систем ИИ. Фундаментальные модели
обучаются на огромных датасетах и могут настраиваться под конкретные задачи,
что делает их гибкими инструментами, подходящими для широкого спектра
приложений. Благодаря своей масштабируемости и доступности облако становится идеальной средой для работы с этими большими моделями, интенсивно
расходующими ресурсы. Доступны как фундаментальные модели с открытым
исходным кодом, так и коммерческие модели генеративного ИИ — для разных
потребностей и бюджета.
Доступность фундаментальных моделей генеративного ИИ в облаке позволяет
бизнесу и разработчикам пользоваться расширенными возможностями новейших ИИ-технологий без необходимости крупных вложений в вычислительную
инфраструктуру. Например, Amazon Bedrock с API позволяет использовать
сторонние фундаментальные модели таких компаний, как stability.ai, Meta,
Mistral, Anthropic, Amazon и AI21. Azure предоставляет доступ API к OpenAI
GPT-4, а 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 AI.
Подготовка и разметка
Чтобы подготовить данные для МО, необходимо выполнить их обработку:
генерацию признаков, проверку данных, оценку модели и ее интерпретацию.
В процессе генерации признаков также выполняется предварительная обработка
наборов данных для их преобразования в формат, ожидаемый алгоритмом МО.
Например, если вы работаете с датасетом, включающим даты, вы можете извлечь день недели, месяц и время года в отдельные признаки, так как они могут
обладать прогностической ценностью для модели. Используйте инструменты
и методы, перечисленные в предыдущем разделе, чтобы привести данные к форме, необходимой для вашей модели МО. Управляемая платформа МО — такая,
как Amazon SageMaker — также предоставляет инструмент очистки и преобразования данных (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.
Данные клиента поглощаются в облаке, а фреймворк МО принимает решение
по заявке.
y
При проектировании этой архитектуры необходимо руководствоваться несколькими фундаментальными принципами.
y Рабочий процесс обучения
1. Наборы данных входят в процесс с использованием S3. Это могут быть
необработанные входные данные или данные, прошедшие предварительную
обработку, из локальных наборов данных.
2. Ground Truth используется для создания высококачественного обучающего
датасета для моделей МО. При необходимости сервис Ground Truth может
произвести разметку данных.
514
Глава 13. Архитектура машинного обучения
Облако AWS
До Интерфейс После
Direct
Connect
Datasol
Локальная
среда
Amazon S3
AWS Lambda
Локальные
модели
SageMaker
Notebook
Amazon ECR
Train/Test
Шлюз API
Пользовательский
интерфейс
Развертывание Мониторинг
модели
модели
Артефакты
модели
Пользователь
Исходный код
Пакетное
преобразование
CodeCommit
CodePipolino
CodeBulid
Процесс сборки
Процесс обучения
Процесс интерфейса
Сборка
AWS Lambda Amazon SNS AWS Lambda
Выход пакетного
преобразования
Amazon DynamoDB
Отслеживание аудита
Обучение
Развертывание
Рис. 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 хранит все метаданные, действия и другие связанные данные
модели для целей аудита.
y
9. Чтобы разместить итоговую модель, развертывается эндпоинт
с соответствующей конфигурацией как часть последнего этапа рабочего
процесса.
Рабочий
процесс сборки
y
10. Экземпляры блокнота SageMaker используются для подготовки
и обработки данных, а также для обучения и развертывания моделей
МО. К этим блокнотам можно обращаться через эндпоинт VPC для
сервиса SageMaker.
11. CodeCommit предоставляет репозиторий исходного кода, инициируя
задания сборки, необходимые для всех нестандартных образов Docker,
используемых SageMaker.
12. Сервис CodePipeline управляет сквозным пайплайном сборки
нестандартных образов Docker и использует сервис CodeBuild для этапа
сборки/тестирования.
y
13. CodeBuild строит нестандартный образ Docker и проводит его юниттестирование, после чего помещает его в Amazon ECR (процесс может
управляться централизованно или бизнес-функциями, которым требуются
инструменты).
y Рабочий процесс развертывания
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) подразумевает, что архитектура МО будет
поддерживать свою функциональность и генерировать разумные результаты
даже при отказе некоторых системных компонентов либо при поступлении неожиданных входных данных. Например, рекомендательная система интернетмагазина должна рекомендовать товары, даже если часть источников данных
(скажем, недавняя история просмотра) временно недоступна. Это обеспечит
непрерывность вовлечения пользователей и потенциальные продажи.
Система мониторинга промышленного оборудования на базе МО может предсказывать необходимость в обслуживании и выявлять сбои. Благодаря отказоустойчивости система будет предоставлять полезную информацию даже в том
случае, если некоторые датчики перестанут работать или будут сообщать ошибочные данные. Модель МО должна выявлять такие аномалии и управлять ими,
предлагая надежную оценку работоспособности оборудования и обеспечивая
безопасную и непрерывную работу в промышленной среде.
При соблюдении этих принципов в архитектурах МО модели могут надежно
работать в различных реальных сценариях, от обеспечения безопасных и эффективных операций в отрасли до предоставления содержательных взаимодействий
в реальном времени в службе поддержки.
Машинное обучение может применяться повсюду. Например, для решения
клиентских задач: прогнозного обслуживания, предоставления точных прогнозов для бизнеса, формирования персонализированных рекомендаций для
конечных пользователей и т. д. Сценарии использования МО не ограничиваются клиентскими задачами, но помогают контролировать IT-приложения
за счет оптимизации рабочей нагрузки с предиктивным масштабированием,
выявлением закономерностей в журналах, исправлением ошибок до того, как
они создадут проблемы в продакшен-среде, или прогнозирование бюджета для
инфраструктуры IT. Таким образом, архитекторы решений должны разбираться
в сценариях использования МО и связанных с ними технологиях.
Ранее в этой книге вы узнали о методологии DevOps, предназначенной для
автоматизации и практической реализации рабочей нагрузки при разработке.
По мере того как МО начинает внедряться повсеместно, методология MLOps
стала играть важную роль при изучении масштабного применения МО в рабочих
MLOps
521
системах. В следующем разделе практическая реализация рабочей нагрузки МО
с MLOps рассматривается более подробно.
MLOps
Рабочий процесс МО представляет собой комплекс операций, которые разработаны и исполняются для формирования математической модели, решающей
некую реальную задачу. Однако эти модели не обладают никакой ценностью,
пока не будут развернуты для реальной эксплуатации (а не останутся подтверждениями жизнеспособности концепции). Чтобы модели МО имели
практическую ценность для бизнеса, они почти всегда требуют развертывания
в продакшен-среде.
По своей сути, процесс MLOps направлен на превращение экспериментальной
модели МО в полностью функциональную рабочую систему. Практика MLOps
еще не сформировалась окончательно, она отличается от традиционной практики
DevOps уникальной природой жизненного цикла разработки МО и производимых ею специфических артефактов МО. В жизненном цикле МО центральное
место занимает выявление закономерностей в обучающих данных, вследствие
чего процесс MLOps особенно чувствителен к изменениям данных, а также
колебаниям в объеме и качестве данных.
Хорошо проработанная практика MLOps должна поддерживать мониторинг
операций жизненного цикла МО, а также текущее наблюдение за моделями
в продакшен-среде. Этот двойной контроль обеспечивает эффективность как
процесса разработки, так и развернутых моделей.
Реализация MLOps позволяет организациям уверенно создавать серьезные
фреймворки MLOps без большого объема кода. Как и в отношении любой другой
рабочей нагрузки, при разработке MLOps следует применять лучшие практики
(безопасность, надежность, высокую доступность, производительность) и учитывать затраты на развертывание жизненного цикла МО. Рассмотрим некоторые
принципы MLOps.
Принципы MLOps
Любые изменения в коде, обучающих данных или модели должны инициировать
процесс сборки в пайплайне разработки МО. Это гарантирует эффективную
работу модели и немедленную реакцию на изменения.
y
Пайплайн МО должен соответствовать следующим принципам MLOps.
y Автоматизация: развертывание моделей МО в продакшен должно быть
автоматизировано. Команде MLOps следует автоматизировать весь процесс
МО, от инженерии данных до инференса модели в продакшен-среде без ручного вмешательства. Автоматизация гарантирует, что в рабочей модели не
будет пробелов в случае изменения обучающих данных и модель останется
522
Глава 13. Архитектура машинного обучения
y
y
y
y
y
актуальной. Пайплайн MLOps может инициировать обучение модели и ее
развертывание на основании таких событий, как календарное планирование,
отправка сообщений, мониторинг, изменения данных, а также изменения
кода обучения модели и кода приложения.
y Контроль версий: один из важнейших принципов MLOps. Версии каждой модели МО и связанного с ней скрипта должны учитываться системой контроля
версий (например, GitHub), чтобы модели оставались воспроизводимыми
и пригодными для аудита.
y Тестирование: системы МО требуют расширенного тестирования и мониторинга. При тестировании каждой системы МО должны учитываться как
минимум три области:
тесты признаков и данных, включающие проверку качества данных и выбор правильных признаков для модели МО;
тесты разработки модели, включающие тесты бизнес-метрик, тесты актуальности модели и тесты проверки эффективности модели;
тесты инфраструктуры МО, включающие тесты API МО, интеграционные
тесты всего пайплайна МО, а также тесты доступности серверов обучения
и эксплуатации.
y Воспроизводимость: каждый этап рабочего процесса МО должен быть воспроизводимым, то есть результаты обучения модели МО, обработки данных
и размещения модели МО должны быть аналогичными для сходных входных
данных. Тем самым обеспечивается устойчивость системы МО.
y Развертывание: MLOps интегрирует принципы МО с культурой DevOps,
уделяя особое внимание CI/CD и непрерывному обучению / непрерывному мониторингу (CT/CM). Посредством автоматизации развертывания
и тестирования MLOps упрощает раннее выявление проблем, что делает
возможным быстрое внесение исправлений и итеративное обучение. Такой
метод упрощает процесс развертывания моделей МО в продакшен-среде,
благодаря чему они остаются эффективными и актуальными.
y Мониторинг: со временем производительность рабочей модели может
снизиться, например из-за дрейфа данных. В таком сценарии необходимо
непрерывное развертывание новых или обновленных моделей, чтобы препятствовать снижению эффективности или улучшать достоверность модели.
Таким образом, после развертывания модели МО следует развернуть систему
мониторинга для гарантии того, что модель МО работает в рамках ожиданий
и продолжает эффективно генерировать надежные и точные результаты. Все
это важно для поддержания общего качества и достоверности результатов,
выдаваемых приложением МО.
После рассмотрения принципов проектирования MLOps давайте рассмотрим
некоторые лучшие практики применения MLOps в рабочей нагрузке.
MLOps
523
Лучшие практики MLOps
Из-за обилия «подвижных частей» (данные, модель, код), а также сложностей
с применением МО при решении бизнес-задач реализовать MLOps может быть
непросто.
y
y
y
y
В соответствии с принципами, описанными в предыдущем разделе, существуют лучшие практики, которые должны применять инженеры МО / full-stackспециалисты по data science при развертывании решений МО в рабочей среде.
Это поможет сократить технический долг и затраты на обслуживание проектов
МО, а также извлечь из них максимальную практическую пользу. Вот некоторые
из таких лучших практик.
y Факторы проектирования: если вы хотите разработать систему МО, которую удобно обслуживать, архитектура системы должна быть модульной и по
возможности слабосвязанной. Слабая связанность (loose coupling) архитектуры позволяет разным командам в организации работать независимо. Это
означает, что такие команды не зависят от других команд, обеспечивающих
необходимую поддержку или услуги. В результате каждая команда работает
быстрее и эффективнее, внося свой вклад в общую ценность и производительность организации.
y Проверка данных: проверка данных играет ключевую роль в успешности
системы МО. В продакшен-среде с данными могут возникать сложности.
Например, статистические свойства рабочих данных отличаются от свойств
обучающих данных, что может быть вызвано потенциальными проблемами со
свойствами, самими обучающими данными или процессом выборки данных.
Кроме того, возможен дрейф данных, который со временем может привести
к изменению статистических свойств данных в очередных пакетах. Дрейф
может повлиять на производительность модели, так как модель была обучена
на данных с разными статистическими характеристиками.
y Проверка модели: повторное использование моделей отличается от повторного использования программного кода. Модели желательно настраивать
для каждого нового сценария. Очень важно провести тщательную проверку
моделей перед их выводом в продакшен-среду. Чтобы убедиться, что модель
эффективно работает на живых данных, важно проверять данные как онлайн,
так и офлайн. Это поможет гарантировать, что прогнозы модели точны и надежны в текущих условиях.
y Отслеживание экспериментов с моделью: все эксперименты, проводимые
с моделями МО, должны тщательно документироваться. Эксперименты в МО
могут включать проверки разных комбинаций кода (в том числе предварительную обработку, обучение и оценку), датасетов и гиперпараметров. Каждая
уникальная комбинация этих элементов производит метрики, которые необходимо сравнивать с результатами других экспериментов. На основе этого
сравнения строится понимание того, какие решения наиболее эффективны,
и проводится соответствующая оптимизация моделей МО.
524
Глава 13. Архитектура машинного обучения
y
y Проверка качества кода: каждая спецификация модели МО (обучающий
y
y
y
y
код, создающий модель МО) должна проходить код-ревью. Проверка качества кода как начальная точка пайплайна, активируемого пул-реквестом, —
хорошая общая практика.
y Соглашения об именовании: соблюдение стандартных соглашений об именовании (таких, как PEP8 для программирования на Python) в коде МО —
эффективная стратегия решения проблем, вызываемых принципом CACE
(Changing Anything Changes Everything, то есть «изменение чего-либо изменяет все»). Последовательные и четкие соглашения об именовании упрощают
понимание и изменение кода. Они не только помогают поддерживать целостность проекта при внесении изменений, но и позволяют новым участникам
команды быстро разобраться в проекте.
y Мониторинг производительности модели: наряду c метриками проекта
(такими, как среднеквадратичная погрешность), вычисляющими поведение модели относительно бизнес-целей, важно отслеживать операционные
метрики (задержка, масштабируемость) для предотвращения потерь со
стороны бизнеса.
y Процесс CT/CM: в продакшен-среде производительность модели может
снижаться из-за таких факторов, как дрейф данных. Таким образом возникает
необходимость в постоянном развертывании обновлений модели в целях
улучшения или поддержания ее достоверности и точности. Процесс CT/CM
играет важную роль в эффективном управлении таким развертыванием. CT
(continuous training, непрерывное обучение) обеспечивает регулярное обновление моделей и их обучение на новейших данных, тогда как CM (continuous
monitoring, непрерывный мониторинг) отслеживает эффективность модели
в реальном времени, выявляя любые проблемы или отклонения, которые
могут возникнуть из-за изменения закономерностей в данных. CT и CM
вместе образуют надежный фреймворк и обеспечивают долгосрочность
и эффективность моделей МО в продакшен-среде.
y Потребление ресурсов: понимание требований системы на этапах обучения
и развертывания чрезвычайно важно для ее эффективной эксплуатации.
Эта информация поможет команде эффективно оптимизировать ресурсы,
используемые для экспериментов, которые, в свою очередь, могут привести к значительной экономии затрат. Правильное управление ресурсами
гарантирует, что для имеющихся задач будет выделен необходимый объем
вычислительной мощности, памяти и т. д., не больше и не меньше. Этот
баланс исключительно важен для поддержания производительности и экономичности проектов МО.
MLOps игpает важнейшую роль в промышленном применении ИИ. MLOps
объединяет МО, инженерию данных и DevOps для эффективного создания,
развертывания и обслуживания систем МО в условиях реальной эксплуатации.
Глубокое обучение стало основным механизмом решения сложных задач МО.
В следующем разделе оно рассматривается более подробно.
Глубокое обучение
525
Глубокое обучение
Основной задачей МО являются прогнозирование и решение сложных задач
с применением NLP (обработки естественного языка), позволяющие компьютерам понимать, интерпретировать и генерировать содержательный и полезный
текст на естественном языке. NLP находит много практических применений,
включая машинный перевод, анализ тональности текста, чат-боты и голосовые
помощники, что позволяет организовать более интуитивные и привычные для
человека взаимодействия с машинами. Хотя для обучения с учителем МО требует заранее определенного набора размеченных данных, глубокое обучение
использует нейросеть для обучения без учителя, чтобы моделировать поведение
человеческого мозга на большом объеме данных, расширяя возможности МО.
Нейросеть представляет собой комплекс алгоритмов, распознающих закономерности в датасетах при помощи процесса, моделирующего работу человеческого
мозга.
При глубоком обучении используется многоуровневая нейросеть, не требующая
предварительной разметки данных. Тем не менее в зависимости от сценария
использования с глубоким обучением можно применять как размеченные, так
и неразмеченные данные. На рис. 13.4 представлена простая модель глубокого
обучения.
Скрытые слои
Входной слой
Выходной слой
Рис. 13.4. Слои глубокого обучения
На диаграмме показано, что модель глубокого обучения состоит из связанных
узлов; входные слои предоставляют входные данные через различные узлы.
Эти данные проходят через несколько скрытых слоев для вычисления вывода и поставляют итоговый вывод модели (инференс) через слой выходных
узлов. Слои входных и выходных узлов считаются видимыми, а обучение
происходит на промежуточных слоях с применением весов и смещений, как
показано на рис. 13.5.
526
Глава 13. Архитектура машинного обучения
Входные
данные
0
1
0
1
1
0.4
0.3
.
y
.
.
Х
0.2
0.9
Метка
Рис. 13.5. Модель нейросети глубокого обучения
На этой диаграмме изображена последовательность скрытых слоев, на которых
к связанным узлам применяются весовые функции для изучения закономерности — по аналогии с тем, как это делает человеческий мозг. Как видно из
диаграммы, данные меток поступают на вход и проходят по ребрам нейронной
сети с весами (в примере — 0.2, 0.4, 0.3 и 0.9).
Вес представляет собой параметр нейросети, который влияет на преобразование
входных данных при прохождении через скрытые слои. По сути, вес определяет
степень, в которой заданный ввод повлияет на вывод. Его можно рассматривать
как силу или интенсивность связи между узлами нейросети.
Например, если вес ребра от узла A к узлу B высок, это подразумевает, что
нейрон A имеет более значимое влияние на нейрон B. Веса, близкие к нулю,
указывают на то, что изменение этого конкретного ввода имеет минимальное
влияние на вывод. Отрицательные же веса предполагают обратную связь —
это означает, что увеличение ввода уменьшает вывод, и наоборот. Механизм
весов является фундаментальным для работы нейронных сетей и обучения на
основе данных.
Описанный метод обучения называется прямым распространением, где данные
перемещаются от входного слоя до выходного. Вывод одного слоя передается на
вход следующего слоя и так далее до получения итогового вывода.
Глубокое обучение
527
Существует и другой метод, называемый обратным распространением. В нем
используется вычисление погрешности в прогнозах сети (расхождения между
тем, что прогнозирует сеть, и фактическим результатом). Сеть применяет
алгоритмы для вычисления ошибок прогнозирования, после чего корректирует
свои внутренние параметры — веса и смещения — на основании этой ошибки.
Корректировка выполняется в обратном направлении, начиная с выходного
слоя, поэтому метод и называется «обратным».
Применяя комбинацию прямого и обратного распространения, нейросеть может обучаться и совершенствоваться. Она обрабатывает данные (прямое распространение), выявляет любые неточности в своих предсказаниях (обратное
распространение), а затем изменяет свои параметры для сокращения ошибок.
Этот цикл составляет основу обучения нейросети, в ходе которого она постепенно
становится более эффективной и точной.
y
y
Глубокое обучение охватывает разные типы нейросетей, подходящих для разных
видов приложений. Два самых популярных варианта:
y сверточные нейронные сети (CNN, Convolutional Neural Networks): хорошо
справляются с обработкой данных в топологии сети (например, изображений),
что делает их высокоэффективными для задач с визуальным вводом — компьютерного зрения и задач классификации изображений;
y рекуррентные нейронные сети (RNN, Recurrent Neural Networks): сильной
стороной RNN является обработка последовательных данных, вследствие
чего они идеально подходят для задач, связанных с пониманием языка и речи
(например, NLP и распознавание речи).
К числу самых популярных фреймворков для построения таких моделей нейросетей принадлежат TensorFlow со встроенной поддержкой для разных типов
архитектур нейросетей и MXNet, также поддерживающий диапазон сетевых
архитектур и известный своей эффективностью и масштабируемостью, особенно
в контексте высокопроизводительных приложений глубокого обучения. Кроме
того, заслуживают упоминания такие популярные фреймворки глубокого обу
чения, как PyTorch, Chainer, Cafe2, ONNX, Keras и Gluon.
В этом разделе приведен общий обзор глубокого обучения. Это очень сложная
тема, и даже для изложения ее основ потребуется целая книга. По каждому из
упомянутых фреймворков также можно найти несколько книг. Тренировка
моделей глубокого обучения требует значительных вычислительных мощностей и может обходиться очень дорого. Тем не менее провайдеры публичных
облачных платформ — такие, как AWS, GCP и Azure — упрощают использование
высокопроизводительных экземпляров на базе GPU для обучения этих моделей
методом оплаты за фактическое использование.
528
Глава 13. Архитектура машинного обучения
Глубокое обучение в реальных условиях
Глубокое обучение чрезвычайно популярно, и существует много сценариев для
его применения в различных отраслях. Рассмотрим несколько примеров.
Здравоохранение: диагностика и профилактика
Модели глубокого обучения помогают специалистам в области здравоохранения, предоставляя второе мнение, а иногда даже выявляя подробности, которые
может упустить человек. Эти модели обучаются на огромных наборах медицинских снимков, учась идентифицировать признаки, связанные с заболеваниями
и симптомами, и могут предсказать вероятность того, что пациент страдает
конкретным заболеванием. Например, Google DeepMind разработал модель
для обнаружения глазных заболеваний на сканах. Анализируя 3D-сканы глаз
пациентов, система глубокого обучения может рекомендовать, каких пациентов
следует направить на лечение.
Беспилотный транспорт: навигация и безопасность
Модели глубокого обучения помогают беспилотным автомобилям понимать
окружение, принимать решения и ориентироваться на местности. Они тренируются на обширных датасетах различных сценариев вождения и обучаются
распознавать объекты (например, пешеходов или другие машины), понимать
дорожные знаки и принимать решения по безопасному вождению (когда следует тормозить или поворачивать). По сути глубокое обучение позволяет этим
машинам интерпретировать и понимать окружающий мир, делая возможным
автоматизированное вождение и повышая уровень безопасности.
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 может помочь с созданием маркетинговых
кампаний или планированием поездок, а Midjourney умеет генерировать изображения за считаные секунды.
Возможно, вы уже встречались с такими приложениями генеративного ИИ, как
ChatGPT, Midjourney, Gemini (ранее Bard), Amazon Q, Claude.ai и т. д. GenAI
многое узнает из собранной информации, в том числе из интернета, и использует
эти знания для разработки нового контента. Он напоминает умного помощника,
способного генерировать объекты без обращения к человеку за их деталями. Тем
не менее важно понимать, что это не волшебство, а результат большой работы
ума и достижений в области технологии.
Но самое интересное в том, что эти фундаментальные модели могут использоваться для множества разных целей. Например, для генерирования творческого
контента, автоматизации службы поддержки с чат-ботами, повышения качества
анализа данных, предоставления персональных рекомендаций, улучшения перевода на другие языки и даже помощи в исследованиях за счет реферирования
Что такое генеративный ИИ?
533
y
y
y
y
y
y
y
сложных документов. В этой главе вы больше узнаете о генеративном ИИ,
включая следующие темы.
y Что такое генеративный ИИ?
y Сценарии применения генеративного ИИ.
y Базовая архитектура систем генеративного ИИ.
y Популярные фундаментальные модели генеративного ИИ.
y Как начать работу с генеративным ИИ.
y Эталонная архитектура генеративного ИИ.
y Изменения в реализации генеративного ИИ.
Приготовьтесь к захватывающему путешествию в мир генеративного ИИ. В этой
главе будут раскрыты многие тайны, на которых основаны выдающиеся способности этой технологии.
Что такое генеративный ИИ?
Генеративный ИИ — искусственный интеллект с выдающимися способностями
к созданию нового контента и генерации идей. Это могут быть диалоги, истории,
графические изображения, видео и даже музыка.
В декабре 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/.
ФМ выделяются своими размерами и универсальностью, что отделяет их от
традиционных моделей МО, предназначенных для конкретных задач: анализа
тональности, классификации изображений, прогнозирования трендов. В отличие
от этих традиционных моделей, требующих сбора размеченных данных, обучения и развертывания для каждой задачи, ФМ предлагают более гибкий подход.
Одна предварительно обученная ФМ может быть адаптирована для разных задач. Более того, эти модели можно приспособить для выполнения специальных
функций, уникальных для конкретной отрасли. Очень важно, что подобную
настройку можно произвести с использованием лишь части данных и вычислительных ресурсов, необходимых для обучения модели с нуля.
y
y
y
Успех ФМ обусловлен тремя основными причинами.
y Архитектура трансформера (разновидность нейросети): играет ключевую
роль. Она эффективна, обладает масштабируемостью, может параллелизироваться и эффективно моделировать отношения входных и выходных данных.
y Контекстное обучение: это революционная парадигма обучения, которая
позволяет снабдить предварительно обученные модели инструкциями для
новых задач или несколькими примерами. Таким образом снимается необходимость в дополнительном обучении на размеченных данных, что позволяет
сразу же применять модели к новым задачам.
y Эмерджентное поведение в масштабе: с увеличением размера модели и наборов данных начинают проявляться не выявленные ранее возможности.
Например, большие модели могут генерировать более связный и соответствующий контексту текст, распознавать сложные закономерности в данных
и даже выполнять такие операции, как распознавание образов и перевод на
другие языки с большей точностью. Они также могут отвечать на вопросы,
требующие многоэтапных рассуждений, предоставлять подробные объяснения и генерировать творческий контент — например, писать музыку или
создавать изображения с пониманием смысловых нюансов. Большие модели
обладают потенциалом для решения задач, которые остаются непосильными
для них, пока модели не достигнут критического размера.
Чтобы вы лучше поняли, как работает генеративный ИИ, рассмотрим некоторые
сценарии его применения.
Сценарии использования генеративного ИИ
Рассмотрим несколько сценариев из разных категорий: взаимодействие с пользователями, производительность сотрудников, эффективность бизнес-операций.
Вы узнаете, как генеративный ИИ расширяет границы существующих ИИ и открывает ряд совершенно новых возможностей.
Сценарии использования генеративного ИИ
535
Преобразование взаимодействий с пользователями
y
y
y
y
Генеративный ИИ изменяет положение в области взаимодействия клиентов
с бизнесом. Например, вы покупаете обувь в интернете. Виртуальный помощник
на базе генеративного ИИ приветствует вас на сайте интернет-магазина и помогает подобрать идеальную пару, соответствующую вашим предпочтениям
в отношении стиля и размера. Он даже покажет вам изображения и ответит на
возникающие вопросы. Ниже приведены другие примеры сценариев, где генеративный ИИ помогает улучшить пользовательский опыт.
y Чат-боты и виртуальные помощники: вы заходите на сайт, и открывается
чат-бот, который предлагает вам помощь. Работа этих чат-ботов обеспечивается генеративным ИИ. Они могут общаться с вами как люди, понимать
ваши вопросы и давать толковые ответы.
y Умные контактные центры: когда вы обращаетесь на горячую линию службы
поддержки, с вами работает генеративный ИИ. Он постарается сделать взаимодействие с вами более персонализированным, эффективным и приятным.
Вы получите быстрые и точные ответы на свои вопросы.
y Персонализация: вы замечали, что рекомендации на таких платформах, как
Netflix и Amazon, соответствуют вашим предпочтениям? В их выборе также
участвует генеративный ИИ. Он учится на вашем поведении и адаптирует
свои рекомендации, чтобы они соответствовали вашим вкусам.
y Модерирование контента: генеративный ИИ помогает поддерживать безопасность и порядок в социальных сетях и на других платформах. Он сканирует
контент, генерируемый пользователями (комментарии, посты и т. д.), и проверяет, что они соответствуют правилам и рекомендациям.
Повышение производительности труда
y
y
Генеративный ИИ не ограничивается клиентскими взаимодействиями: он также
увеличивает производительность труда работников. Представьте, что вы работаете над проектом и вам нужно подготовить по нему отчет. Чтобы не начинать
с нуля, можно воспользоваться генеративным ИИ для написания вводной части
и перечисления основных пунктов. Такая заготовка станет хорошим началом,
и вы сможете добавлять собственный опыт и аналитическую информацию. Несколько сценариев, в которых генеративный ИИ помогает повысить эффективность труда работников.
y Интерактивный поиск: когда вам нужна информация, вы пользуетесь поисковой системой. Генеративный ИИ сделает эти системы более разумными.
Вы сможете задавать вопросы на естественном языке, ИИ поймет их и даст
правильные ответы.
y Создание контента: написание статей и отчетов может занимать много времени. Генеративный ИИ поможет и с этим. Он можете генерировать части
контента (например, сводки или пояснения), которые могут использоваться
для создания хорошо проработанных документов.
536
Глава 14. Архитектура генеративного ИИ
y
y Реферирование текста: представьте, что вы работаете с длинной исследо-
y
вательской статьей. Чтобы не читать все страницы подряд, можно поручить
генеративному ИИ составить краткое резюме основных положений. Это
сэкономит время и поможет вам быстрее понять самую важную информацию.
y Создание кода: важнейшая часть работы программистов — написание кода.
Генеративный ИИ может помочь с этим, предлагая фрагменты кода на основании поставленной задачи. Такая помощь ускоряет кодинг и делает процесс
разработки более плавным.
При интеграции генеративного ИИ в корпоративные сценарии очень важно разобраться с юридическими аспектами генерации контента. Вы должны понимать
источник контента, а четкое установление прав собственности необходимо для
предотвращения споров о правах на интеллектуальную собственность. Существуют потенциальные препятствия — например, проблемы нарушения авторского
права и конфиденциальности данных. Чтобы предотвратить эти риски, предприятие может рассмотреть возможность разработки собственных помощников на
базе генеративного ИИ с использованием проприетарных данных. Такой подход
не только позволит избежать юридических затруднений, но и гарантирует, что
сгенерированный контент будет соответствовать специфическим потребностям
организации и отражать ее ценности.
Оптимизация бизнес-операций
y
y
y
Генеративный ИИ помогает также улучшать различные параметры эксплуатации. На заводе состояние оборудования отслеживается при помощи датчиков.
Генеративный ИИ анализирует данные от этих датчиков и предсказывает,
насколько вероятно возникновение проблем с оборудованием. Это позволяет
планировать техническое обслуживание заранее, предотвращая неожиданные
сбои и прерывания в работе. Ниже перечислены некоторые сценарии, где генеративный ИИ помогает улучшить бизнес-операции.
y Интеллектуальная обработка документов: бизнесу приходится работать
со множеством документов. Генеративный ИИ способен читать и понимать
эти документы, извлекая из них значимую информацию автоматически.
При этом экономится время и снижается риск ошибок. Например, модель
генеративного ИИ может поглощать документы по ипотечному креди
тованию и отвечать на вопросы о ставке кредита, условиях платежа, сроке
и т. д.
y Прогнозное обслуживание: для компаний, эксплуатирующих оборудование,
очень важно заранее узнать, когда ему понадобится обслуживание. Генеративный ИИ анализирует данные, полученные от машин и систем, и прогнозирует
требования к обслуживанию. Таким образом предотвращаются неожиданные
поломки, а время простоев сводится к минимуму.
y Контроль качества и визуальная проверка: в производстве очень важно следить, чтобы продукция соответствовала высоким стандартам. Генеративный
Базовая архитектура систем генеративного ИИ
537
y
ИИ анализирует изображения продукции, выявляя дефекты или расхождения, которые может упустить человеческий глаз.
y Аугментация (обогащение) данных: обучение ИИ-моделей требует больших
объемов данных. Генеративный ИИ способен создавать синтетические данные, которые могут использоваться для повышения точности и надежности
таких моделей.
В этом разделе вы узнали о возможных сценариях использования генеративного
ИИ. Пришло время посмотреть, что же происходит за кулисами. Следующий
раздел посвящен архитектуре генеративного ИИ.
Базовая архитектура систем
генеративного ИИ
y
y
y
y
В системах генеративного ИИ центральное место занимает большая фундаментальная модель. ФМ — крупномасштабные модели, прошедшие предварительное
обучение на огромных датасетах и способные дополнительно настраиваться
или адаптироваться для широкого спектра задач и применений. Чтобы понять
архитектуру генеративного ИИ, разобьем ее на простые компоненты.
y Генератор: основной элемент, который генерирует новые данные — изображения, текст, музыку или другие формы контента. Генератор узнает закономерности и отношения из существующих данных и использует эти знания
для производства нового, похожего контента. Например, генератор вносит
случайный шум в генерирование изображений и производит изображения,
напоминающие обучающие данные.
y Скрытое пространство: концептуальное пространство, в котором модель
представляет данные в сжатой форме. Это компактное представление данных,
которое используется генератором для создания нового контента; оно представляет собой векторное пространство сокращенной размерности. Его можно
сравнить с некой тайной «книгой рецептов», которую использует художник,
чтобы создавать разные типы картин. Например, скрытое пространство может
предоставлять разные варианты авторского стиля при генерировании текста.
При синтезе изображений скрытое пространство может предоставлять такие
признаки, как цвет, текстура и т. д.
y Функция потерь: оценка того, насколько хорошо сгенерированный контент
соответствует желаемому выводу. Функция потерь помогает модели учиться
и совершенствоваться со временем за счет сокращения различий между генерируемыми и реальными данными. Представьте мастера, который объясняет
ученику, насколько его работа близка к идеалу или далека от него. Следуя
этим рекомендациям, ученик обучается и совершенствуется.
y Обучающие данные: существующие данные, на которых обучается модель.
Это могут быть изображения, текст, аудио или любой другой тип доступного контента. Подобно тому как шеф-повар учится, пробуя разные блюда,
538
Глава 14. Архитектура генеративного ИИ
генератор узнает, что он должен создавать, по примерам. Например, чтобы
сочинять песни, он должен слушать существующие композиции.
Типы генеративных моделей
Прежде чем рассматривать генеративные модели, поговорим о том, чем они отличаются от классических дискриминативных моделей МО. Типичная дискриминативная модель предназначена для того, чтобы различать классы или категории данных. В отличие от генеративных моделей, которые создают новые
данные, дискриминативные концентрируются на различии существующих точек
данных на основании их признаков. Эти модели предсказывают вероятность
определенного результата, базируясь на входных данных. Типичные примеры
дискриминативных моделей МО — логистическая регрессия, метод опорных
векторов и т. д. Эта концепция была подробно рассмотрена в главе 13 «Архитектура машинного обучения».
Дискриминативные модели приспособлены для классификации или разметки
текста на основании заранее определенных группировок. Они часто применяются
для таких задач, как распознавание лиц, где их обучение строится на выявлении
конкретных признаков или атрибутов в изображении лица.
Генеративные модели устроены иначе. Как видно из диаграммы, они пытаются понять закономерности и структуру в данных. Они словно изучают неизвестные им правила игры, а затем используют их для создания чего-то, что
напоминает исходную игру. В отДискриминативные
Генеративные
личие от них дискриминативные
модели различают сущности. Они
напоминают детективов, которых
обучили выявлять различия между
объектами. Дискриминативные модели обычно применяют для задач
обучения с учителем, где целью
является классификация или регрессия, тогда как генеративные
модели применяют там, где нужно понять распределение данных
Рис. 14.1. Генеративные
или сгенерировать новые точки
и дискриминативные модели
данных.
Генеративный ИИ охватывает различные модели, создающие новый контент.
Рассмотрим самые популярные из них.
Генеративно-состязательные сети (GAN)
Генеративно-состязательные сети (GAN, Generative Adversarial Networks) состоят из двух компонентов: генератора и дискриминатора. Роль генератора
Базовая архитектура систем генеративного ИИ
539
заключается в производстве контента, а задача дискриминатора — оценка аутентичности контента, проверка его на подлинность. Они вступают в свое рода «состязание», где генератор стремится создать контент, достаточно убедительный,
чтобы «обмануть» дискриминатора. По мере продолжения процесса генератор
последовательно совершенствуется в создании контента, который выглядит все
более реалистично. На рис. 14.2 изображена схема работы модели GAN.
Скрытая случайная переменная
Реальные данные
Дискриминатор
Условие
истинно?
Генерируемые
фиктивные данные
Генератор
Корректирующее
обучение
Рис. 14.2. Процесс обучения GAN
y
y
y
На диаграмме представлена базовая структура GAN. Рассмотрим каждый шаг
на примере создания изображений.
y Генератор: этот компонент GAN получает случайный шум на входе. Такой
шум часто называется «скрытой случайной переменной». Роль генератора
заключается в производстве данных, похожих на реальные, на которых он обучался. Это как художник в процессе обучения, который изначально создает
случайные наброски на основании некоторых базовых образцов. Например,
генератор начинает с создания случайных изображений, которые должны
напоминать знаменитые картины.
y Реальные данные: подлинные экземпляры данных, для имитации которых
проектировалась сеть GAN. Они служат эталоном качества данных, создаваемых генератором. В нашем примере это знаменитые картины из прошлого —
шедевры, которые генератор пытается воспроизвести. Например, картины
таких художников, как Ван Гог или Пикассо, передаются GAN как примеры
настоящего искусства.
y Генерируемые фиктивные данные: генератор использует входной шум для
создания новых точек данных. Предполагается, что эти данные неотличимы
540
Глава 14. Архитектура генеративного ИИ
y
y
y
от реальных, хотя они полностью генерируются моделью. Это новые изображения, создаваемые генератором, когда он пытается воспроизвести качество
и стиль настоящих картин. Например, генератор производит изображения,
которые имитируют манеру мазка и цветовые палитры работ Ван Гога или
Пикассо.
y Дискриминатор: этот компонент берет как настоящие, так и фиктивные
данные, сгенерированные генератором. Его задача — различить их, по сути
решая, является ли каждый полученный им образец реальным или фиктивным. Дискриминатор можно сравнить с искусствоведом, который изучает
шедевры и сгенерированные изображения, решая, являются новые изображения подлинными произведениями искусства или имитациями. В нашем
примере дискриминатор проверяет изображения, пытаясь определить, какие
из них являются настоящими картинами Ван Гога или Пикассо, а какие —
подделками.
y Условие: дискриминатор принимает решение о том, являются данные реальными или фиктивными, и предоставляет эту информацию генератору
в виде обратной связи. Искусствовед (дискриминатор) оценивает сгенерированные изображения и в виде обратной связи указывает, какие детали
выдают подделку. Например, дискриминатор замечает, что цветовая палитра
сгенерированного изображения не соответствует стилю исходного художника,
и помечает изображение как подделку.
y Корректирующее обучение: на основании оценок дискриминатора генератор регулирует свои параметры, пытаясь создать более качественные
имитации, которые с большей вероятностью обманут дискриминатора.
Цикл обратной связи продолжается, и дискриминатор также развивает
свою способность отличать реальные данные от имитаций. Этот состязательный процесс продолжается, пока генератор не научится создавать
реалистичные данные. На основании обратной связи обучающийся художник (генератор) учится на полученной критике и совершенствует
свои навыки, чтобы создавать более убедительные работы. Например, он
может скорректировать цветовую палитру или стиль мазка, чтобы лучше
воспроизводить стиль шедевров.
Генератор и дискриминатор по сути участвуют в непрерывной игре. Генератор
пытается производить все более реалистичные данные, а дискриминатор стремится усовершенствовать свое умение отличать реальные данные от фиктивных.
Обучение завершается, когда дискриминатор уже не может надежно отличать
фиктивные данные от реальных; это означает, что выходные данные генератора
получаются убедительно реалистичными.
Сети GAN находят практические применения в разных областях; многие популярные инструменты пользуются этой моделью.
Базовая архитектура систем генеративного ИИ
541
Вариационные автоэнкодеры (VAE)
Представьте огромную кучу деталей Lego разных форм и размеров, которые
нужно компактно упаковать в маленькую коробку. Но есть условие: можно
хранить только инструкции по сборке исходных конструкций, а не сами детали. Именно так вариационные автоэнкодеры (VAE, Variational AutoEncoders)
работают с данными.
Энкодер — это процесс анализа каждой конструкции Lego и создания кратких
инструкций по ее сборке с меньшим числом деталей. Скрытое пространство — та
самая коробка, где хранятся сжатые инструкции. Декодер — использование этих
инструкций для сборки новой конструкции, похожей на оригинал, из другого
набора деталей. VAE сжимает большие сложные данные (например, изображения) в компактный код, а затем генерирует новые данные, восстанавливая их
из этого кода.
Этот процесс применяется для таких задач, как создание новых изображений,
музыки или любого цифрового контента, воспроизводящего стиль исходных
данных. На рис. 14.3 изображена схема кодирования и декодирования рисунка
с использованием VAE.
Входные изображения
Энкодер
Кодировки
изображений
Декодер
Реконструкция изображений
Рис. 14.3. Процесс реконструкции изображений с использованием VAE
y
y
На диаграмме изображен процесс реконструкции изображений с использованием VAE. Ниже приведена краткая схема работы VAE в этой задаче на примере
реконструкции лица человека.
y Входные изображения: исходные изображения, передаваемые системе
VAE. Цель — восстановить эти изображения после кодирования и декодирования. Например, у вас есть набор изображений, где каждое представляет собой фотографию человеческого лица, качественную и в высоком
разрешении.
y Энкодер в схеме VAE получает входные изображения и сжимает их
в меньшее, более компактное представление, называемое скрытым пространством или кодировками изображений. Этот процесс подразумевает
анализ важнейших признаков и закономерностей входных изображений.
Кодировщик анализирует входные фотографии и сжимает каждую из них
в меньший набор чисел, описывающих ключевые признаки лиц: формы
глаз, носа, рта и т. д. Представьте, что вы создаете уникальный код, который представляет лицо существенно меньшим объемом данных, чем
в исходном изображении.
542
Глава 14. Архитектура генеративного ИИ
y
y Кодировки изображений: на этой стадии энкодер преобразует входные
y
y
изображения в набор кодировок, представляющих ключевые признаки изображений в существенно меньшей размерности по сравнению с исходными
изображениями. В контексте VAE эти кодировки также отражают вероятностное распространение входных данных. Эти наборы чисел (кодировки)
отражают самые важные признаки фотографий, хранящиеся в компактной
форме, которую можно рассматривать как подробное описание изображений.
Для фотографий лиц эти признаки могут отражать разнообразие черт лица
разных людей.
y Декодер получает кодировки и пытается восстановить исходные изображения. Он использует сжатые данные для генерирования изображений, как
можно более близких к исходным входным изображениям. Декодер действует
как художник, которому заказали написать портрет по описанию. Он берет
разные числовые коды и использует их для воссоздания фотографий лиц.
При этом декодер пытается изобразить каждое лицо как можно точнее на
основании только этого компактного кода.
y Реконструированные изображения: итоговый вывод VAE. Это изображения,
которые были реконструированы декодером по их кодировкам. Качество
этих изображений зависит от того, насколько хорошо VAE обучен сжатию
и реконструкции данных. Результат представляет собой серию новых фотографий лиц, сгенерированных VAE. Эти реконструированные изображения
должны быть достаточно близки к исходным фотографиям. Положив их рядом с оригиналами, вы увидите, что они очень похожи, хотя восстановленные
изображения могут быть слегка замылены или незначительно отличаться
из-за потери деталей в ходе сжатия.
Фактически процесс описывает способность VAE изучать эффективные представления данных и генерировать новые данные, напоминающие исходный
ввод. Процесс используется в разных приложениях, включая шумоподавление
и ретуширование дефектов, а также как генеративная модель для создания новых
изображений, сходных по свойствам с обучающим датасетом.
Генеративные модели на базе
трансформеров
Модели этой категории — такие, как GPT-4 — строятся на базе архитектуры
«трансформер». Сильной стороной этой архитектуры являются понимание
и генерирование последовательностей данных (например, текста). Модель анализирует закономерности в языке и контексте, что позволяет ей генерировать
связный и релевантный текст.
На рис. 14.4 изображен рабочий процесс модели-трансформера — комплексной
разновидности нейросетей, применяемой в задачах обработки естественных
языков (NLP) — машинном переводе, генерировании текста и т. д. Рассмотрим
каждый этап процесса на примере машинного перевода.
Базовая архитектура систем генеративного ИИ
543
y
y Слой эмбеддинга (input embedding layer): процесс начинается со слоя, где
y
отдельные элементы (например, слова в предложении) преобразуются
в числовые векторы, которые могут обрабатываться моделью. Скажем,
модели передается предложение «How are you?», и каждое слово преобразуется в числовой вектор. Можно сказать, что с каждым словом связывается уникальное число-идентификатор, чтобы модель могла понимать
их и работать с ними.
y Позиционное кодирование (positional encoding): позиционное кодирование
добавляется к векторам, чтобы передать модели информацию о позиции
каждого слова в предложении, так как у трансформера нет внутреннего
понимания порядка слов. Например, вместе с числом-идентификатором
каждому слову может присваиваться метка позиции. «How» помечается как
первое слово, «are» — как второе, «you» — как третье. Это помогает модели
учитывать порядок слов при обработке.
Слой эмбеддинга
Позиционное кодирование
Энкодер
Энкодер — обрабатывает вывод
Многопоточный механизм внимания
Декодер
Декодер — генерирует вывод
Нейронная сеть с прямой связью
Нормализация и остаточные
соединения
Выходной слой
Рис. 14.4. Компоненты генеративных моделей на базе трансформера
544
Глава 14. Архитектура генеративного ИИ
y
y Энкодер: объединенный ввод (эмбеддинг и позиционное кодирование) пере-
y
y
y
y
y
дается энкодеру. Энкодер обрабатывает входные данные, сохраняя контекст
каждого слова относительно других слов в предложении. Он читает предложение и воспринимает смысл каждого слова в контексте всего предложения.
Энкодер анализирует слова с идентификаторами и позиционными метками,
чтобы понять смысл предложения. Например, он замечает, что «How» в первой позиции обычно означает вопрос.
y Многопоточный механизм внимания (multi-head self-attention): внутри
энкодера модель назначает разным частям ввода разные веса. Модель словно рассматривает разные параметры значения слова, изучая другие слова,
окружающие его. Энкодер обращает особое внимание на то, как каждое слово
в предложении соотносится с каждым другим. Например, он замечает, что
«How» соединяется с «you» для формирования вежливого вопроса о благополучии собеседника.
y Нейронная сеть с прямой связью (feed-forward network): затем обработанная информация проходит через нейронные сети с прямой связью, которые
дополнительно обрабатывают данные на каждом слое, чтобы уточнить и абстрагировать представление. Эти сети уточняют информацию от механизма
внимания — почти как группа редакторов, работающих над черновиком
рукописи, чтобы точнее передать смысл текста.
y Нормализация и остаточные соединения (normalization and residual
connections): они применяются в процессе работы для поддержания потока
данных и снижения риска ошибок преобразования данных на более глубоких
уровнях сети. Эти элементы гарантируют, что информация, проходящая через
модель, не слишком приглушена и усилена. Чтобы предотвратить разрастание
ошибок на уровнях сети, эти компоненты работают как контрольные точки,
которые помогают направлять данные по правильному пути.
y Декодер: после обработки энкодером входные данные поступают к декодеру,
который использует их для генерирования вывода. Он получает обработанные
данные от энкодера и начинает создавать преобразованное предложение —
например, переводить предложение на другой язык или генерировать ответ
в диалоге. Декодер получает обработанную информацию от энкодера и начинает генерировать вывод. Если речь идет о переводе текста, то он начинает
формировать переведенное приложение.
y Выходной слой: итоговый вывод декодера отправляется выходному слою,
который переводит сложный вывод нейросети в удобочитаемый формат —
например, предложение на языке, понятном для человека. На этой стадии
итоговый вывод начинает обретать форму. Если модель переводит предложение, то этот слой начинает строить перевод на основании всей обработанной
информации.
Модель-трансформер читает и понимает входные данные (предложения,
абзацы и т. д.), обрабатывает их для понимания контекста и генерирует вывод
Базовая архитектура систем генеративного ИИ
545
на основании этого понимания. Для предложения «How are you?» энкодер
модели обрабатывает вопрос, а декодер генерирует ответ или перевод по
одному слову с учетом как информации от энкодера, так и уже сгенерированного вывода.
Можно считать, что энкодер проверяет входную информацию, а декодер создает
результат. Например, GPT-4 работает на базе модели-трансформера. Когда вы
даете ему отправную точку, он генерирует осмысленный текст с учетом контекста. Модель использует «внимание» (self-attention) для определения того, какие
слова в начальной точке важны и как они соединяются. Так она может понять,
о чем вы спрашиваете, и дать содержательный ответ.
Другие важные генеративные модели
y
y
Кроме уже упомянутых типов, заслуживают внимания следующие генеративные
модели.
y PixelCNN и PixelRNN генерируют изображения пиксель за пикселем, сохраняя неочевидные детали и зависимости в изображении. Представьте, что
вы рисуете картину пиксель за пикселем, следя за тем, чтобы каждый пиксель
соответствовал окружающим.
y Потоковые модели учатся преобразовывать одно распределение данных
в другое, что позволяет им генерировать данные, соответствующие заданному
распределению. По сути, это рецепт, который превращает простые ингредиенты в изысканное блюдо по конкретным инструкциям.
У этих генеративных моделей есть свои сильные стороны и потенциальные
применения, вследствие чего они подходят для широкого спектра задач, от
генерирования изображений до создания текста. Это разнообразие обогащает
спектр возможностей генеративного ИИ.
Важность настройки гиперпараметров и регуляризации
Настройка гиперпараметров и регуляризация — средства настройки и безопасности архитектур генеративных API. Например, при генерировании изображений
можно настраивать такие гиперпараметры, как скорость обучения, определяющая, насколько быстро учится модель; если скорость будет слишком большой,
модель может изучить неправильные закономерности (как человек, который
пытается сыграть мелодию на пианино, но нажимает на клавиши слишком
сильно или слишком слабо). Регуляризация может включать такие приемы, как
исключение (dropout), при котором некоторые нейроны случайным образом
игнорируются в процессе обучения для повышения надежности модели (по
аналогии с тем, как футбольные команды тренируются без некоторых игроков,
чтобы избежать излишней зависимости от одного конкретного игрока). Это
чрезвычайно важно для того, чтобы системы работали хорошо и создавали
высококачественный контент. Оценим степень их важности.
546
Глава 14. Архитектура генеративного ИИ
Настройка гиперпараметров
Гиперпараметры можно рассматривать как рукоятки и переключатели, управляющие процессами обучения систем генеративного ИИ и создания им контента.
Они влияют на такие параметры, как скорость обучения, уровень детализации
результатов и баланс между креативностью и точностью.
Представьте, что вы пытаетесь подобрать идеальную температуру духовки для
выпечки пирога. Слишком жарко — и пирог подгорит; недостаточно жарко —
и он не пропечется. С настройкой гиперпараметров дело обстоит примерно так
же. Она помогает корректировать параметры, чтобы система ИИ обучалась
наилучшим образом, создавая идеальный контент.
Например, гиперпараметры могут управлять длиной мелодий, темпом или
инструментами, используемыми в системе генерирования музыки. Настройка
гиперпараметров обеспечит гармоничное звучание музыки и ее соответствие
заданному стилю.
Регуляризация
Регуляризация напоминает страховочную сетку для канатоходцев. Она не позволяет системе ИИ увлечься и начать создавать слишком экзотический или
нереалистичный контент. Это механизм контроля над выводом, который следит
за тем, чтобы система работала корректно.
В системе генеративного ИИ регуляризация помогает предотвратить пере
обучение. Напомним, что переобученная система очень хорошо работает на
обучающих данных, но у нее возникают проблемы с новыми, не встречавшимися
ранее данными. Методы регуляризации моделируют включение незначительных
штрафов в отдельные части процесса обучения, чтобы система лучше обобщала
и создавала более разнообразный и креативный контент.
Например, регуляризация в системе генерирования изображений может следить
за тем, чтобы создаваемые изображения содержали согласованные цвета и объекты и не казались слишком зашумленными или странными.
Настройка гиперпараметров и регуляризация играют важную роль в тонкой
настройке производительности систем генеративного ИИ и обеспечивают
создание высококачественного, целостного и реалистичного контента. Без
них система может создавать контент, который будет слишком скучным или
хаотичным и бессмысленным. Подобно тому как шеф-повар регулирует время
готовки и добавляет специи, чтобы получить идеальное блюдо, настройка гиперпараметров и регуляризация корректируют систему генеративного ИИ для
создания креативного контента, соответствующего желаемому результату. Они
следят, чтобы система придерживалась правильного пути и создавала интересный и релевантный контент.
Фундаментальные модели генеративного ИИ
547
Фундаментальные модели генеративного ИИ
y
y
Область генеративного ИИ стремительно развивается. Разные организации
расширяют ее границы и запускают мощные фундаментальные модели, прокладывая путь для инноваций. Запуск таких моделей, как ChatGPT, придал
очевидное ускорение этой тенденции. Как признанные технологические гиганты,
так и стартапы активно участвуют в революции генеративного ИИ, стремясь
разрабатывать более сложные и функциональные ФМ. Ниже перечислены некоторые популярные ФМ в области генеративного ИИ.
y 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/.
y OpenAI: OpenAI — исследовательская организация, которая занимается
созданием и распространением открытых и этичных ИИ. Она разработала
ряд моделей генеративного ИИ, в числе которых:
DistilGPT2: эффективная модель генерирования текста;
GPT-3: гибкая модель для генерирования текста и ответов на вопросы;
GPT NeoXT: мощная модель для разнообразных языковых задач;
GPT-3.5: эффективный генератор длинных, связных текстов;
GPT-4: мультимодальная модель, приближенная к деятельности человека;
CLIP: анализ отношений между текстом и изображениями;
CLIP-Guided Diffusion: создание изображений по текстовым промтам;
DALL·E: генерирование изображений по промтам на естественном языке;
MuZero: модель обучается играм, играя сама с собой;
548
Глава 14. Архитектура генеративного ИИ
Text-to-Speech (TTS): преобразование текста в естественно звучащую
y
y
речь;
Whisper: модель для преобразования аудио в текст;
Embeddings: преобразование текста в числовые данные;
Moderation: оценка текста на предмет чувствительного содержания;
Sora: генерирование видео по текстовым промтам.
OpenAI работает над GPT-5 — самой свежей на момент написания этой книги
и самой совершенной модели, находящейся в стадии обучения. Дополнительную информацию о моделях OpenAI можно получить на официальном
веб-сайте: https://openai.com/. OpenAI предоставляет подробную информацию о своих моделях, исследованиях, публикациях и доступе к API на своей
платформе.
y Google: компания Google стала первопроходцем в области ИИ и МО. Она
разработала несколько моделей генеративного ИИ, в том числе:
Google Gemini: большая языковая модель для машинного перевода, создания контента и ответов на вопросы;
BERT: модель, улучшившая понимание контекста в обработке языков;
BigGAN: генерирует реалистичные изображения в высоком разрешении
для создания визуального контента;
Text-to-Text Transfer Transformer (T5): автоматизирует генерирование
контента для различных задач NLP;
Модели Flan T-5: адаптированы для специальных задач обработки языков,
включая текст и код;
Pathway Language Model (PaLM): принадлежит к числу больших языковых моделей, специализируется на генерировании текста и переводах;
LaMDA: модель разработана для диалоговых приложений, имитирует
человеческий стиль общения;
Falcon-7B и Falcon-40B: модели, разработанные для машинного перевода,
ответов на вопросы и генерирования текста;
Chinchilla by DeepMind: большая языковая модель, ориентированная на
задачи генерирования текста и машинного перевода.
В настоящее время Google сосредоточилась на Gemini и строит более со
вершенную версию модели, расширяя ее моделью подписки. За дополни
тельной информацией о моделях ИИ и исследованиях компании Google
обращайтесь на веб-сайт Google AI (https://ai.google/) или на сайт DeepMind
(https://deepmind.com/).
y Anthropic: исследовательская организация, которая ставит своей целью
создание общих масштабируемых ИИ, которые соответствуют человеческим
ценностям и предпочтениям. Организация получила значительные инвестиции от крупных технологических компаний, включая Amazon (5 миллиардов
долларов) и Google (2 миллиарда). В Anthropic было разработано семейство
Фундаментальные модели генеративного ИИ
549
y
y
моделей генеративного ИИ, которое называется 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.
y Meta (Facebook) AI: Meta AI занимается разработкой и применением ИИ
для различных продуктов и сервисов, связанных с социальными сетями, коммуникациями, созданием контента и т. д. Ею были разработаны следующие
модели генеративного ИИ:
RoBERTa: расширенная модель BERT, достигающая лучшей производительности благодаря расширенному обучению и точной настройке.
DETR: упрощает обнаружение объектов в изображениях, соединяя сверхточные нейросети с архитектурой трансформера;
Llama: диапазон языковых моделей, предназначенных для понимания
и генерирования текста; модели доступны в разных размерах для разных
вычислительных потребностей и применений;
BlenderBot: разговорные ИИ, которые могут поддерживать содержательные и связные взаимодействия, моделирующие диалоги между людьми;
Faiss: библиотека для эффективного поиска и кластеризации, идеально
подходящая для обработки больших датасетов и сложных задач на поиск
сходства.
Информацию о последних достижениях в области генеративного ИИ от Meta
можно найти на веб-сайте https://ai.meta.com/.
y Microsoft: компания Microsoft широко использует предложения OpenAI,
она вложила в их разработку 10 миллиардов долларов и предлагает схему
OpenAI MaaS (Model as a Service, модель как услуга). Она также разработала
такие модели генеративного ИИ, как Turing-NLG и MPT-7B. В рамках MaaS
компания Microsoft предоставляет модели OpenAI: GPT4, GPT3.5, DALL-E
550
Глава 14. Архитектура генеративного ИИ
y
y
и Whisper. Чтобы больше узнать о каталоге моделей Microsoft Azure, посетите
страницу предложений генеративного ИИ https://azure.microsoft.com/en-us/
products/machine-learning/generative-ai.
y 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 специализируется на графических процессорах
y
(GPU), играх, облачных вычислениях, ИИ и многих других направлениях.
Она создала несколько моделей генеративного ИИ, включая StyleGAN2
и GANVerse3D. Вы можете больше узнать о моделях Nvidia на странице
https://www.nvidia.com/en-us/ai-data-science/generative-ai/.
y
y Jasper.ai: технологическая компания, предоставляющая решения в области
y
генеративного ИИ для маркетинга. Она разработала модель генеративного
ИИ, которая называется Jasper, а также запустила Jasper AI Copilot для расширения своих предложений. Дополнительная информация о Jasper доступна
на сайте https://www.jasper.ai/.
y Hugging Face: технологическая компания, предоставляющая инструменты
и платформы с открытым исходным кодом для NLP. В частности, она создала несколько моделей генеративного ИИ, в числе которых Bloom, BloomZ
176B, Lyra-Fr 10B и Lyra-Mini. Дополнительную информацию о Hugging
Face и ее моделях генеративного ИИ можно найти на официальном сайте
компании, в разделе Model Hub, который содержит подробные описания
и доступ к моделям. Поиск можно начать по ссылке https://huggingface.co/
docs/hub/en/models-the-hub.
Приведенный выше список неполон, но включает наиболее популярные модели.
В области ФМ для генеративного ИИ ведутся серьезные разработки. Можно
ожидать, что с продолжением исследований в ней появятся еще более мощные
и гибкие модели.
Как начать работу с генеративным ИИ
Чтобы начать работу с генеративным ИИ, вам понадобятся инструменты и платформы, подходящие для ваших потребностей. Кем бы вы ни были — рядовым
пользователем, желающим пообщаться с искусственным интеллектом, или
разработчиком/теоретиком МО, собирающимся создавать сложные приложения, — существует множество ресурсов, которые помогут вам исследовать мир
генеративного ИИ.
Фундаментальные модели генеративного ИИ
551
В следующих подразделах кратко описываются возможные типы пользователей
и даются рекомендации инструментов, с помощью которых они могут начать
свое знакомство с генеративным ИИ.
Конечные пользователи
y
y
y
y
y
y
Рядовые пользователи, желающие применить возможности генеративного ИИ
в своих повседневных занятиях — создании контента, написании электронных
писем, эффективном обучении, — могут воспользоваться следующими инструментами.
y ChatGPT предоставляет удобного чат-бота на базе GPT-3.5, усовершенствованной языковой модели. Бот генерирует ответы на естественном языке
в зависимости от полученного ввода и может вести беседы на разные темы.
На момент написания книги с ChatGPT можно было работать по адресу
https://chat.openai.com бесплатно, с возможностью обновления до GPT-4
с расширенной функциональностью за ежемесячную подписку стоимостью
$20. Также можно ознакомиться с различными специализированными приложениями из GPT Store от сообщества создателей.
y Claude — модель генеративного ИИ, разработанная в Anthropic. Claude специализируется на генерировании текста для электронной почты, аннотаций,
историй и т. д. Описание возможностей Claude доступно на странице https://
claude.ai/chat/; система нацелена на создание контента, соответствующего
человеческим ценностям.
Google
Gemini (ранее Bard) — чат-бот от Google. Как и ChatGPT, Gemini
y
может давать подробные и неформальные ответы на заданные вопросы и генерировать разные виды текста: стихи, код, сценарии, электронные письма
и т. д. С его возможностями можно ознакомиться на странице https://gemini.
google.com/app. Gemini можно считать наследником Bard — первого приложения Google, предназначенного для ответов на вопросы.
y Copilot предоставляет сервис генеративного ИИ от компании Microsoft,
использующий такие модели, как GPT-4. Он облегчает ведение диалогов на
естественном языке, упрощая взаимодействие и общение с системами на базе
ИИ. Сервис доступен по адресу https://www.bing.com/chat.
y Amazon Q — сервис от AWS, разработанный для повышения производительности и лучшего принятия решений в организациях. Это мощный инструмент,
способный быстро предоставлять актуальные ответы на важные вопросы,
помогать с решением задач, генерировать контент и выполнять задачи с использованием разнообразной информации, содержащейся в базах данных
компании, коде и корпоративных системах. Дополнительную информацию
об Amazon Q можно найти на странице AWS https://aws.amazon.com/q/.
y Perplexity AI представляет собой прорыв в технологии поиска и действует
как расширенный чат-бот на базе ИИ, выходящий за рамки традиционных
поисковых систем. Perplexity AI применяет методы МО и NLP, чтобы давать
552
Глава 14. Архитектура генеративного ИИ
точные ответы на широкий спектр вопросов. Он предоставляет пользователям быстрый доступ к информации по различным темам, упрощая процесс
поиска. Кроме того, он стимулирует пользователей к более глубокому изу
чению интересующей их темы, задавая уточняющие вопросы или выясняя
дополнительные подробности, что расширяет понимание темы пользователем
и повышает эффективность его обучения. Дополнительную информацию см.
на https://www.perplexity.ai/.
Существует много других приложений ИИ для различных целей от таких компаний, как Jasper, Midjourney, Canva и Luminar. С помощью этих инструментов
генеративного ИИ пользователи могут оптимизировать свои задачи, развивать
креативность и повышать эффективность повседневной работы, от создания
контента до ведения интерактивных диалогов. Все инструменты обладают собственным набором уникальных возможностей.
Технические специалисты
y
Разработчики приложений, специалисты по data science, инженеры МО могут
применять генеративный ИИ и тем самым в несколько раз повышать свою
продуктивность, генерируя с его помощью код, уточняя уже разработанные
модели и обращаясь к существующим моделям через API. Рассмотрим эту тему
подробнее.
y Повышение продуктивности за счет генерирования кода: инструменты на
базе генеративного ИИ предоставляют возможность генерирования кода,
чтобы разработчик уделял больше времени бизнес-логике, а не написанию
однообразного вспомогательного кода. Назовем некоторые популярные
инструменты генерирования кода.
Amazon CodeWhisperer: AWS предоставляет этот сервис, использующий
NLP и МО для генерирования фрагментов кода на основании запросов
на естественном языке. Например, можно указать CodeWhisperer сгенерировать функцию Lambda, которая отправляет сообщение электронной
почты с использованием SES, и CodeWhisperer выдаст следующий код:
# Создание функции Lambda, отправляющей сообщение с использованием SES
def lambda_handler(event, context):
client = boto3.client('ses')
response = client.send_email(
Source='XXXXXXXXXXXXXXXXXXXXX',
Destination={
'ToAddresses': [
'XXXXXXXXXXXXXXXXXXXXX',
],
},
Message={
'Subject': {
'Data': 'Hello from SES!',
},
'Body': {
Фундаментальные модели генеративного ИИ
},
},
553
'Text': {
'Data': 'Hello from SES!',
},
)
print(response)
return response
CodeWhisperer работает более чем с 15 языками программирования, включая
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 и C#. Пример работы интерпретатора 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, предоставляемые известными облачными платформами и организациями.
Рассмотрим их подробнее.
Использование ФМ генеративного ИИ в приложениях
публичных облачных провайдеров
y
y
Интеграция ФМ генеративного ИИ стала более доступной, чем когда-либо,
благодаря широкому спектру облачных платформ, предоставляющих API. Рассмотрим некоторые из этих популярных платформ и их возможности.
y AWS открыла доступ к Amazon Bedrock и Agents for Amazon Bedrock в рамках своих усилий по достижению лидерских позиций в облачных ИИ, для
чего AWS предлагает усовершенствованные решения ИИ и формирует
партнерские отношения с ведущими поставщиками ФМ. Amazon Q — новый
помощник на базе ИИ, адаптированный для профессионального применения
и обученный на 17-летнем опыте AWS, — воплощает новаторский подход
AWS к интеграции ИИ в рабочий процесс, повышая эффективность и креативность в корпоративных средах.
y Amazon Bedrock: надежная облачная платформа, предоставляемая AWS
и разработанная для обучения, создания и развертывания моделей МО.
Amazon Bedrock предоставляет обширное семейство API для различных
задач, включая NLP, распознавание образов и речи. Bedrock предоставляет
доступ к ФМ от Amazon и ведущих организаций в области ИИ — таких, как
AI21 Labs, Anthropic, Cohere, Meta и Stability AI. Чтобы начать разработку
приложений на базе генеративного ИИ с использованием Amazon Bedrock,
необходимо выбрать ФМ, подходящую для ваших целей. Это можно сделать
через Amazon Bedrock Console или API. После выбора модели ФМ ее можно
бесшовно интегрировать в приложение при помощи Amazon Bedrock API.
Фундаментальные модели генеративного ИИ
555
y
y
y
Доступны такие ФМ, как Amazon Titan для обобщения текста, Jurassic-2 для
языковых моделей, действующих по инструкциям, и Claude 3 для ведения
осмысленного диалога и создания контента. Amazon Bedrock можно запустить
по ссылке: https://aws.amazon.com/bedrock/.
y 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/
dg/studio-jumpstart.html.
y Microsoft Azure: Microsoft активно внедряет технологии генеративного ИИ
во всем спектре своих решений, включая Azure, M365, Dynamics 365, Power
Platform, Windows и GitHub, демонстрируя мощь генеративного ИИ в линейках своих продуктов. У Microsoft есть предложения для корпоративных
клиентов через Azure OpenAI Service, которые отличаются от прямых решений
OpenAI за счет таких функций, как частные сети (private networks), высокий
уровень безопасности, масштабируемость и локализованная доступность
сервиса (региональное присутствие).
y 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.
y
y 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. Архитектура генеративного ИИ
y
Значимым расширением семейства ФМ для 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 — общедоступный вариант, цена которого на момент написания
книги, как ни удивительно, точно совпадала с ценой M365 Copilot.
y Google Cloud Generative AI предоставляет доступ к мощным, предварительно
обученным генеративным моделям-трансформерам от Google. Google Cloud
Generative API можно использовать для подключения к таким моделям, как
DALL-E 2 для генерирования изображений, T5 для задач NLP и BigGan для
генерирования изображений высокого разрешения по простым промтам на
естественном языке. Чтобы начать работать с сервисом 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).
У каждой платформы есть свои преимущества, которые позволяют создавать
приложения генеративного ИИ для разнообразных сценариев использования
и отраслей. Несмотря на доступность многих вариантов ФМ, для успеха приложения очень важно подобрать оптимальную модель. Посмотрим, как выбрать
лучшую ФМ для поставленных целей.
Фундаментальные модели генеративного ИИ
Таблица 14.1. ФМ от провайдеров публичных облачных платформ
Провайдеры
публичных облачных
платформ
Доступные поставщики ФМ
Доступные ФМ
AWS
Amazon Anthropic
AI21 Labs
Cohere
Meta
Stability.ai
Titan Text Embeddings
Titan Multimodel Embeddings
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
557
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. Архитектура генеративного ИИ
y
y
y
y
y
Для предотвращения галлюцинаций модели, а также обеспечения точности
и надежности моделей генеративного ИИ существуют определенные приемы
и стратегии.
y Качество и количество данных: убедитесь, что для модели используются
разнообразные обучающие данные высокого качества, соответствующие
предметной области приложения. Наличие большого и разнообразного
датасета помогает модели понять широкий спектр контекстов и сокращает
риск галлюцинаций. Разнообразный датасет может включать текст из разных
предметных областей, языков и стилей NLP. При обучении чат-бота разно
образный датасет может помочь модели понять различные пользовательские
запросы и предоставлять ответы, соотносящиеся с контекстом.
y Тонкая настройка, или дообучение (fine-tuning): после исходного обучения
на большом датасете модель настраивается на данных конкретной предметной
области. Дообучение адаптирует модель к конкретной задаче или области
знания, снижая вероятность генерирования галлюцинаторного контента.
Примером служит тонкая настройка предварительно обученной языковой
модели (такой, как Amazon Titan или GPT-4) на медицинской литературе
для создания медицинского чат-бота, который может отвечать на вопросы,
предоставлять информацию и помогать профессиональным медикам понять
сложные медицинские тексты.
y Промт-инжиниринг: создайте четкие и соотносящиеся с контекстом промты
(входящие запросы) при взаимодействии с моделью. Хорошо структурированные промты помогают модели выдавать более точные ответы, соответствующие ожиданиям пользователя. Вместо туманного «Расскажи мне
о мировой истории» следует создать структурированный промт, например
«Расскажи вкратце о ключевых событиях Второй мировой войны». Генерирование образовательного контента будет эффективнее благодаря понятным
и конкретным промтам, обеспечивающим получение точной информации.
y Генерация с аугментированной выборкой (RAG, Retrieval-Augmented
Generation): реализуйте такие методы, как RAG, для получения релевантной
информации из базы знаний или документов и используйте полученный
контекст для генерирования ответов. Такой подход основывает вывод модели на фактах и информации из определенной области знаний, что снижает
риск галлюцинаций, обеспечивает получение релевантной информации
о продуктах из базы данных и использование этой информации для генерирования точных описаний продуктов. Платформы электронной коммерции
могут реализовать RAG для создания подробных и основанных на фактах
описаний продуктов.
y Фильтрация по порогу: установите порог для качества или релевантности
ответа. Принимайте от модели только те ответы, которые соответствуют заданному уровню достоверности или релевантности, и отбрасывайте или уточняйте при помощи промтов ответы ниже установленного порога — например,
Фундаментальные модели генеративного ИИ
561
y
y
y
y
y
отклонение ответов со степенью уверенности ниже 0,8 обеспечивает их высокое качество. Чаты поддержки могут использовать фильтрацию по порогу
для предоставления надежных ответов на запросы пользователей.
y Рецензирование человеком: организуйте ревью и модерирование человеком,
чтобы отфильтровать ответы, потенциально содержащие галлюцинации. Рецензенты могут оценивать и исправлять выводы модели для обеспечения точности и безопасности. Платформы генерирования контента могут нанимать
рецензентов, чтобы обеспечить качество контента и избежать предоставления
неверной информации.
y Непрерывный мониторинг и обратная связь: отслеживайте производительность модели и собирайте обратную связь от пользователей. Используйте
эту обратную связь для выявления и устранения галлюцинаций модели и ее
улучшения со временем. Собирайте обратную связь от пользователей при
взаимодействиях с чат-ботом и анализируйте ее на предмет возможных усовершенствований. Чат-боты и виртуальные помощники могут непрерывно
развиваться на основании обратной связи, чтобы предоставлять пользователям более качественную поддержку.
y Меры безопасности: реализуйте в модели меры безопасности и ограничения,
чтобы предотвратить генерирование вредоносного, необъективного или неподходящего контента; включите в чат-боты фильтры ненормативной лексики для блокирования оскорблений. Интернет-сообщества и социальные
платформы применяют меры безопасности для поддержания уважительной
и дружественной атмосферы.
y Ограничения предметной области: четко определите и сообщите пользователям масштаб и ограничения модели. Это поможет управлять пользовательскими ожиданиями и снизит вероятность выдачей моделью галлюцинаторных
ответов на запросы, выходящие за рамки ее компетенции. Например, объясните пользователям, что погодный чат-бот не может давать медицинские
советы. Особенно полезно определять четкие границы для специализированных чат-ботов (планировщиков поездок, прогнозов погоды и т. д.).
y Регулярные обновления и обслуживание: поддерживайте актуальность
модели новейшими данными и достижениями в области ИИ. Регулярные обновления и обслуживание могут улучшить общую эффективность и сократить
частоту галлюцинаций. Обновите языковую модель новейшими терминами
и языковыми конструкциями. Новостные агентства используют обновленные
языковые модели для генерирования сводок новостей в реальном времени.
Объединяя эти стратегии, разработчики и организации могут свести к минимуму
риск галлюцинаций модели, создавая более надежные и достоверные системы
генеративного ИИ.
Компании развертывают приложения генеративного ИИ во внутренней среде,
прежде чем осуществлять их широкое внешнее развертывание. Такой подход
создает буфер, сокращающий риск поставки ошибочного или неподходящего
562
Глава 14. Архитектура генеративного ИИ
контента. Внутреннее развертывание позволяет организациям уточнять модели
ИИ в контролируемой среде, где последствия ошибок менее серьезны, а ошибки
можно быстро исправить. Сотрудники, знакомые с контекстом и тонкостями
бизнеса, могут предоставить ценную обратную связь по результатам модели,
выявляя любые нерелевантные или неверные ответы, сгенерированные ИИ.
Например, компания может развернуть во внутренней среде чат-бот на базе
ИИ для обслуживания запросов от поддержки IT или HR. Взаимодействуя
с чат-ботом, сотрудники могут сообщать о любых аномалиях или ситуациях,
когда бот предоставляет странные или неточные ответы. Цикл обратной связи
позволяет компаниям проводить настройку модели ИИ, улучшая ее точность
и релевантность, прежде чем развертывать ее в клиентской среде.
Поэтапное развертывание не только снижает риски, связанные с галлюцинациями ИИ, но и формирует доверие к технологии — как внутри организации,
так и среди ее клиентов. К тому моменту, когда приложение генеративного ИИ
будет представлено внешним пользователям, оно будет тщательно проверено
и настроено, что обеспечит более надежные и эффективные взаимодействия
с пользователем.
Рассмотрим референсную архитектуру приложения на базе генеративного ИИ.
Референсная архитектура генеративного ИИ
на примере ассистента по ипотечному
кредитованию
Процесс приобретения недвижимости часто пугает потенциальных покупателей,
что отчасти связано с огромным объемом документов, которые им приходится
заполнять. Часто покупатели обнаруживают, что им требуется больше времени,
чтобы разобраться во всех тонкостях. Пытаясь понять важность того, что они
подписывают (особенно в контексте ипотеки), покупатели теряются, чувствуют
себя беспомощными и подавленными. Решение этой проблемы помогает улучшить общее впечатление клиента и выстроить доверительные отношения между
покупателями и банком в процессе подачи заявки и закрытия сделки. Решение
на базе генеративного ИИ способно облегчить бремя покупателя и помочь ему
разобраться в условиях кредитования без помощи отраслевых экспертов или
юристов.
В этом разделе рассматривается архитектура приложения-ассистента по ипотечному кредитованию. Центральное место в приложении занимает реферирование
(создание краткого резюме) важнейших ипотечных документов. Представленная архитектура использует бессерверный подход с AWS, а для работы с ФМ
генеративного ИИ в ней используется Amazon Bedrock. Стоит заметить, что эту
архитектуру также можно реализовать на базе другой технологии по вашему
выбору.
Референсная архитектура генеративного ИИ 563
Amazon Bedrock – Anthropic Claude 2 ФМ
промт = вопрос + шаблон промта + фрагмент kendra
Отраслевые документы
Пользователь
Amazon Lex
AWS Lambda
Amazon Kendra
Amazon S3
Рис. 14.5. Виртуальный ассистент для ипотечного кредитования,
построенный на базе генеративного ИИ
На архитектурной диаграмме (рис. 14.5) изображено приложение виртуального
ассистента (VA) на базе Amazon Lex — сервиса, предоставляемого AWS для
построения бессерверных чат-ботов. VA имеет интуитивно понятный интерфейс, в котором пользователи могут общаться и искать ответы на конкретные
вопросы, относящиеся к их ипотечной документации. Виртуальный ассистент,
использующий понимание и средства обработки естественного языка, интерпретирует вопросы и промты пользователей, а затем обращается к выдержкам
из отраслевых документов, проиндексированным 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), влияющими на разнообразие и качество результатов. Схлопывание
мод возникает, когда модель генерирует однообразные или повторяющиеся
результаты из-за своей неспособности полностью отражать разнообразие целевого распределения данных. Модель фиксируется на подмножестве возможных
данных, игнорируя более широкий спектр вариаций в датасете.
Если обучать модель генерации, например, новостных статей, схлопывание
может проявляться в том, что модель будет многократного повторять одни и те
же заголовки или содержание вместо создания разнообразных статей. Даже при
наличии обширного датасета модель может выдавать лишь незначительные
вариации одной и той же новости, что резко снижает полезность результата.
Разработчики могут эффективно предотвращать схлопывание мод распределения,
внедряя цели, способствующие разнообразию контента, производя тонкую настройку гиперпараметров и вводя фактор случайности; таким образом улучшается практическая ценность и универсальность генеративного ИИ в разных применениях.
Проблемы с интерполяцией скрытого пространства
Интерполяция скрытого пространства — интересное свойство генеративного
ИИ, которое позволяет моделям генерировать промежуточные результаты между
двумя точками скрытого пространства. Тем не менее у нее есть свои проблемы,
связанные с содержательностью и качеством генерируемых результатов. Суть
проблемы с интерполяцией скрытого пространства заключается в том, что генерирование вывода между точками скрытого пространства не всегда порождает
семантически осмысленный и связанный контент. Генерируемые промежуточные
состояния могут требовать большей целостности и релевантности.
Допустим, вы хотите разработать генеративную модель, которая создает изображения с плавными переходами между разными художественными стилями
(например, изображение переходит от стиля Ван Гога к стилю Пикассо) при
сохранении визуальной целостности. При интерполяции между двумя изображениями разных стилей полученные переходы могут казаться размытыми,
искаженными или семантически несвязными. Это снижает их предполагаемую
плавность и художественную ценность результата.
y
Чтобы генеративные модели работали лучше (особенно при создании промежуточных результатов), разработчики применяют специальные приемы для повышения эффективности обучения и создания результатов. Рассмотрим их кратко.
y Разделенное обучение представлениям: этот метод помогает модели изучать признаки с их четким разделением. Например, если модель обучается
распознаванию лиц, она учится независимо различать такие признаки, как
566
Глава 14. Архитектура генеративного ИИ
y
y
возраст, прическа или очки. Это помогает модели генерировать более точные
и реалистичные переходы или изменения.
y Настройка методов интерполяции: процесс интерполяции можно описать
как заполнение пропусков между двумя известными точками. В контексте
генеративных моделей настройка этих методов означает, что шаги (или переходы) между двумя результатами становятся более плавными и логичными.
Таким образом предотвращаются неожиданные, нереалистичные изменения
при генерировании моделью серии изображений или звуков.
y Использование обучения с частичным привлечением учителя: этот прием
использует в ходе обучения комбинацию размеченных (известных) и неразмеченных (неизвестных) данных. Он помогает модели делать более эффективные предположения о неразмеченных данных благодаря закономерностям,
обнаруженным в размеченных данных. Такой подход может повысить качество заполнения моделью пропусков или переходов, делая результат более
связным и реалистичным.
При использовании этих методов с генеративной моделью, производящей серию
результатов (например, кадров видео или шагов преобразования), результаты
изменяются плавно и выглядят осмысленно, тем самым повышаются их общее
качество и полезность при решении творческих задач.
Этические соображения и злоупотребления
Вопросы этики и потенциальные злоупотребления технологиями генеративного
ИИ стали важными проблемами современной технологической сферы. Выдающиеся способности ИИ по созданию контента и манипуляций с ним могут
использоваться во вред: для создания дипфейков, распространения ложной
информации или генерирования непристойного контента. Такая деятельность
ведет к возникновению серьезных этических проблем, а также создает угрозы
для доверия и целостности.
Представьте, что генеративный ИИ создает фейковые видеоролики с участием
публичных деятелей, знаменитостей или политиков. Злоумышленники могут
создавать дипфейки, в которых политики делают ложные заявления или совершают неправомерные поступки. Такие видеоролики могут вводить в заблуждение,
манипулировать общественным мнением или наносить репутационный ущерб.
Учет этических факторов и предотвращение злоупотреблений в генеративном
ИИ исключительно важны для сохранения доверия и честности в цифровую
эпоху. Объединяя строгое модерирование контента, средства аутентификации,
ответственные руководства по использованию ИИ, нормативную базу и просветительскую работу, мы можем защититься от злоупотреблений технологиями
генеративного ИИ. Эти коллективные усилия направлены на то, чтобы генеративный ИИ ответственно и этично работал на пользу общества.
Указанные проблемы подчеркивают сложности при работе с генеративным ИИ.
Для их решения необходимо объединять технические инновации, соображения
Итоги
567
этики и нормативные меры. Кроме того, для решения этих проблем и обеспечения
ответственного и полезного применения генеративных моделей чрезвычайно
важно проводить непрерывные исследования и разработки в сфере ИИ.
Итоги
В этой главе мы погрузились в удивительный мир генеративного ИИ, начав
с подробного объяснения, что же это такое. Мы рассмотрели разнообразные
сценарии, которые стали возможными при использовании генеративного ИИ,
от повышения качества взаимодействия с пользователями до увеличения производительности сотрудников и оптимизации параметров бизнес-операций.
Чтобы понять базовую архитектуру систем генеративного ИИ, мы выделили
несколько типов генеративных моделей, включая GAN, VAE и модели на базе
трансформеров. Была подчеркнута важность настройки гиперпараметров и регуляризации в конструировании эффективных архитектур генеративных ИИ.
В контексте ФМ были описаны некоторые популярные ФМ генеративного
ИИ, предоставляемые ключевыми игроками в этой области — Amazon, OpenAI,
Google, Nvidia и другими. Эти модели лежат в основе разработки приложений
на базе генеративного ИИ.
Для читателей, планирующих приступить к работе с генеративным ИИ, были
приведены рекомендации о том, как это лучше сделать, предназначенные для
разных групп пользователей. Конечные пользователи могут исследовать генеративный ИИ при помощи чат-ботов, программисты могут применять их для
генерирования кода, а инженеры-разработчики интегрировать ФМ генеративного ИИ в приложения.
Мы также обсудили такой важный вопрос, как выбор подходящей ФМ, соответствующей специфическим требованиям проекта и характеристикам данных.
Чтобы поддерживать точность и предотвратить галлюцинации модели, мы рассмотрели варианты исходных стратегий работы с генеративным ИИ.
Кроме того, была представлена референсная архитектура ассистента по ипотечному кредитованию на базе генеративного ИИ. Ассистент помогает разобраться в сложных ипотечных документах, упрощая процедуру приобретения
недвижимости.
Глава завершается описанием проблем с реализацией генеративного ИИ,
включая проблемы стабильности обучения, схлопывания мод распределения,
интерполяции скрытого пространства и этические проблемы, связанные с потенциальными злоупотреблениями.
В этой главе была заложена основа для серьезного изучения генеративного ИИ,
его применения, моделей и проблем; она подготовит вас к дальнейшим исследованиям и практической реализации решений с применением искусственного
интеллекта.
ГЛАВА 15
ПЕРЕРАБОТКА АРХИТЕКТУРЫ
УНАСЛЕДОВАННЫХ СИСТЕМ
Современные организации работают в непростой среде. Темп изменений ошеломляет. Контрольно-надзорные органы устанавливают все новые требования
к отчетности и безопасности, новые технологии меняют ожидания и восприятие
потребителей, а экосистема постоянно развивается с появлением на рынке новых
игроков. В результате организации переопределяют свои бизнес-модели, чтобы
внедрить в них ориентированность на клиента, адаптивность и технологии,
необходимые для привлечения талантов, сохранения конкурентоспособности
и роста.
Модернизация приложений стала важнейшим компонентом новых бизнесмоделей, требующих быстрого развертывания сред разработки/тестирования,
экспериментов с новыми идеями и разработки новых продуктов и сервисов.
Кроме устранения необходимости вложений в дорогостоящую и громоздкую
инфраструктуру, новая система открывает возможность инноваций в широком
спектре доступных технологий.
Унаследованными (легаси) системами называются приложения, остающиеся
развернутыми в дата-центре десятилетиями без сколько-нибудь значительных
изменений. Эти системы считаются устаревшими, а их обслуживание усложняется стремительно изменяющейся технологической средой. Унаследованные
системы определяются возрастом и неспособностью удовлетворять растущие
потребности бизнеса из-за используемой в них архитектуры и технологии.
Часто крупные корпорации используют унаследованные приложения для
решения критически важных повседневных бизнес-задач. Унаследованные
системы широко распространены во многих отраслях: здравоохранении, финансах, транспорте, производстве, цепочках поставок и т. д. Часто компаниям
приходится тратить значительные суммы на обслуживание и поддержку таких
систем и разбираться в их архитектуре. Переработка архитектуры и модернизация унаследованных приложений помогают организациям становиться
более адаптивными, применять инновации и оптимизировать затраты и производительность.
Проблемы унаследованных систем
569
y
y
y
y
y
y
В этой главе вы узнаете о проблемах с унаследованными приложениями и методах переработки их архитектуры. Попытка переписать сложные унаследованные приложения с нуля повышает риск остановок работы бизнеса, поэтому мы
предложим рефакторинг приложений или вариант миграции на более гибкую
инфраструктуру. В этой главе рассматриваются следующие темы.
y Проблемы использования унаследованных систем.
y Определение стратегии модернизации систем.
y Методы модернизации унаследованных систем.
y Определение стратегии облачной миграции для унаследованных систем.
y Миграция с мейнфреймов на публичные облачные платформы.
y Модернизация унаследованного кода генеративным ИИ.
К концу главы вы узнаете о сложностях и драйверах модернизации унаследованных систем. Будут рассмотрены различные стратегии и приемы модернизации.
Поскольку организации все чаще переходят на публичные облачные платформы,
вы также узнаете об облачной миграции унаследованных систем.
Проблемы унаследованных систем
Унаследованные приложения создают значительные проблемы для организации. С одной стороны, существуют критически важные приложения, которые
использовались организацией в течение многих лет. С другой стороны, унаследованные приложения сдерживают темпы ее модернизации.
В высококонкурентной среде конечные пользователи ищут самые современные,
технологически продвинутые приложения. Вся новая функциональность обычно
появляется с последними версиями ПО, а старые приложения ограничивают
возможность добавления функций, полезных для клиентов.
На рис. 15.1 показаны некоторые важные проблемы, с которыми сталкиваются
организации, использующие унаследованные системы.
Унаследованная система
Отставание от
Несовместимость
пользовательских с другими системами
потребностей
Высокие затраты
на обслуживание
и обновление
Недостаток
квалификации
и документации
Рис. 15.1. Проблемы унаследованной системы
Уязвимости в системе
корпоративной
безопасности
570
Глава 15. Переработка архитектуры унаследованных систем
Прежде чем браться за решение проблемы, важно четко понять ее суть. В следующем разделе проблемы унаследованных систем рассматриваются более подробно.
Отставание от потребностей пользователей
Ориентация на пользователя играет ключевую роль в успехе бизнеса, а отставание от новейших технологических достижений может значительно ему
навредить. Вспомните компанию Nokia, которая когда-то доминировала на глобальном рынке мобильных телефонов. Около десятилетия назад в игру вступили
смартфоны, но Nokia продолжала работать с унаследованной системой, что почти
довело ее до банкротства. Аналогичная история произошла с Kodak — одной
из самых крупных компаний по производству фотоаппаратов. Ей не удалось
выдержать темп внедрения цифровых инноваций, что привело к банкротству
Kodak в 2012 году. Известно множество примеров крупных компаний, которые
прекратили свое существование из-за трудностей с модернизацией унаследованных технологий и внедрением инноваций.
Пользователи предъявляют весьма высокие требования в современном ландшафте быстро меняющихся технологий и яростной конкуренции. Организациям
приходится меняться с учетом требований пользователей. С развитием технологий пользователь движется вместе с ними и выбирает самые современные
и популярные приложения. Ваши конкуренты могут вырваться вперед, если
они предоставят новую функциональность, необходимую пользователям. Один
из недавних примеров — компания Google, первопроходец в области ИИ/МО,
которая могла бы разработать технологию генеративного ИИ намного раньше.
Однако OpenAI стремительно запустила ChatGPT, опередив Google и заставив
ее наверстывать упущенное. Все это привело к тому, что Google потеряла часть
рынка генеративного ИИ. Эти примеры подчеркивают, насколько важно внедрять новые технологии для поддержания конкурентных преимуществ.
Унаследованные системы также создают проблемы для внутренних корпоративных приложений. Старые системы, построенные для мейнфреймов, в основном
используют режим командной строки. С другой стороны, сотрудники нового
поколения требуют более удобных средств для выполнения повседневных задач. Возможно, вам понадобится дополнительно убеждать руководство, которое
десятилетиями работало с унаследованными системами и привыкло к ним.
Технология, занимающая важное место в крупных компаниях, должна обновляться и распространяться на системы, построенные много лет назад. Компании,
у которых основные системы работают на устаревших локальных технологиях,
сталкиваются с серьезными испытаниями, пытаясь обеспечить современный
пользовательский опыт. Многие системы являются результатом множественных
слияний и поглощений, приведших к дроблению хранилищ данных, лишним
затратам на инфраструктуру и замедлению разработки. Все это ведет к неэффективному принятию решений, недостатку адаптивности бизнеса, медленной
отзывчивости на запросы клиентов и высоким затратам на обслуживание. В таких
Проблемы унаследованных систем
571
условиях службе ИТ будет трудно соответствовать требованиям внутренних
стейкхолдеров и внешних клиентов.
Высокие затраты на обслуживание и обновление
Унаследованные системы были созданы давно и работали десятилетиями,
и может показаться, что они требуют меньших затрат. Но со временем общая
стоимость владения оказывается более высокой, так как поддержка и обновление
старых систем обычно обходятся дороже.
Такие обновления часто недоступны в готовом состоянии, и обслуживание
систем требует множества обходных решений. Многие унаследованные системы плохо совместимы с автоматизацией, что подразумевает больше участия
человека.
Унаследованные системы обычно содержат много проприетарных программ,
что приводит к значительному увеличению лицензионных отчислений. Кроме
того, старое ПО уже не поддерживается поставщиками, а приобретение дополнительной поддержки после окончания жизненного цикла может обойтись очень
дорого. С другой стороны, современные системы часто используют технологии
с открытым исходным кодом, которые снижают общие затраты. Простои уна
следованных систем могут отнимать больше времени и повышать расходы на
эксплуатацию из-за многолетнего технического долга и трудностей с отладкой
кода. Специалистов по обслуживанию унаследованных систем (на таких языках,
как DB2, COBOL, Fortran, Delphi и Perl) трудно найти, они значительно повышают стоимость найма и риск для системы.
Унаследованные приложения работали десятилетиями, и за это время было
внедрено множество изменений, но неиспользуемый код не был удален, что
вызвало значительный технический долг. Любая инициатива по сокращению
технического долга будет рискованной из-за неизвестных последствий и зависимостей. В результате организациям приходится вкладывать средства в ненужный
код и обслуживание системы из опасений нарушить ее работу.
При этом надо иметь в виду, что модернизация унаследованных систем может
обходиться дорого из-за неизвестных зависимостей и возможных простоев.
Принимая решение о модернизации, необходимо провести тщательный анализ
ее экономического эффекта, а также определить окупаемость. Так как стейкхолдеры обычно хотят видеть немедленный выигрыш от модернизации, получить
средства на ее проведение может быть непросто.
Нехватка квалификации и документации
Унаследованные технологии (в частности, мейнфреймы) содержат множество
сложных компонентов, зависящих друг от друга. Это большие проприетарные
и дорогостоящие серверы, к которым будет трудно получить доступ, если кто-то
захочет независимо развить навыки их использования. Будет трудно получить
572
Глава 15. Переработка архитектуры унаследованных систем
ресурсы на разработку приложения и еще труднее найти людей с опытом работы
со старыми технологиями и операционными системами.
Часто унаследованные системы существуют десятилетиями, и бˆольшая часть
тех, кто умеет ими управлять, уже на пенсии. Кроме того, таким системам может
понадобиться документация, в которой отражена многолетняя работа над ними.
Уход старых сотрудников может быть чреват значительной потерей знаний.
Нехватка знаний увеличивает риски при изменении системы из-за неизвестных
зависимостей. Добавление любой, даже незначительной функциональности затруднено сложностью системы и нехваткой компетенций.
Новые революционные технологии — расширенная аналитика, МО, генеративный ИИ, IoT (интернет вещей) — строятся на новых технологических
платформах. Так как новые технологии плохо интегрируются с устаревшими
системами, организация может проиграть конкуренту, если она не использует
все возможности современных технологий. Современная система формирует
имидж инновационной организации, привлекательной для молодых талантов.
Разработка и обучение еще больше увеличивают расходы на унаследованные
технологии.
Автоматизация часто помогает сократить расходы за счет уменьшения объема
человеческого труда. В современных системах доступны многочисленные инструменты автоматизации (пайплайны DevOps, код-ревью, автоматизированное
тестирование), которые невозможно использовать в унаследованных системах,
что приводит к дополнительным затратам.
Уязвимости в системе корпоративной безопасности
Безопасность входит в число основных приоритетов любой организации или
системы. Унаследованное приложение в старой операционной системе (такой,
как Windows XP или Windows 2008) создает уязвимости для безопасности
из-за отсутствия поддержки поставщиком. Поставщики программ постоянно
выявляют новые угрозы безопасности и выпускают патчи для закрытия прорех
безопасности в новейших версиях своих продуктов. Любой унаследованный
продукт, о прекращении поддержки которого объявил поставщик, не будет получать новые патчи безопасности, в результате чего приложение, работающее
в старой версии, сталкивается с различными угрозами.
Проверки работоспособности системы часто игнорируют старые приложения,
и те становятся более уязвимыми для атак. Всего одна уязвимость может привести к тому, что злоумышленники получат доступ к приложению, базе данных
и критически важной информации.
Кроме уязвимостей безопасности, унаследованные приложения сложнее обслуживать из-за необходимости обеспечивать комплаенс. Так как нормативы
изменяются со временем, для повышения безопасности обработки и использования данных в унаследованные системы также приходится вносить изменения,
Проблемы унаследованных систем
573
обусловленные требованиями местного законодательства и контрольно-надзорных органов.
Например, требования Общего регламента ЕС по защите персональных
данных (GDPR, General Data Protection Regulation) предписывают, чтобы
каждая система предоставляла пользователю возможность запросить удаление его данных. Хотя современные системы могут изначально предоставлять эту функциональность на уровне автоматизации и самообслуживания,
в унаследованных системах это требование приходится выполнять вручную
и с большими сложностями.
Обеспечение комплаенса может привести к увеличению расходов на эксплуатацию и времени обслуживания.
Несовместимость с другими системами
Системам приходится взаимодействовать не только с конечными пользователями, но и с другими системами. Эти системы могут принадлежать другим отделам,
клиентам, партнерам или поставщикам. Разные системы могут обмениваться
данными в стандартном формате, который тоже изменяется со временем. Почти
каждые несколько лет в стандарты форматов файлов и данных вносятся изменения для повышения эффективности обмена данными, и в большинство систем
поэтому тоже приходится вносить изменения. Сопротивление изменениям
и использование старых форматов могут привести к тому, что унаследованная
система окажется несовместимой с новыми и в итоге ею не захотят пользоваться
ни поставщики, ни партнеры. Неспособность обеспечить соответствие требованиям стандартов добавляет существенный бизнес-риск из-за сложных обходных
решений и потери производительности.
Разработка обходного решения для простых требований бизнеса может
усложнить систему. Современные системы строятся на сервис-ориентированной архитектуре, что упрощает их адаптацию к любым новым требованиям за
счет независимого добавления новых сервисов. Старые системы часто основаны
на монолитной архитектуре, и добавление новой функциональности означает,
что придется перестраивать и заново тестировать всю систему. Современные
архитектуры ориентированы на API, они легко интегрируются с другими системами для снижения нагрузки. Например, приложение для вызова такси может
использовать Google Maps для навигации GPS (Global Positioning System)
и Facebook или X для аутентификации пользователей. Отсутствие API усложняет эти интеграции в унаследованных системах, что приводит к появлению
сложного специально написанного кода.
Унаследованное приложение может столкнуться с проблемами масштабирования при возрастании нагрузки от зависимой последующей системы. Часто
унаследованные приложения строятся с монолитной архитектурой и зависят от
оборудования. С масштабируемостью в монолитных системах возникают большие проблемы, так как система не может масштабироваться горизонтально из-за
574
Глава 15. Переработка архитектуры унаследованных систем
привязки к оборудованию, а вертикальное масштабирование ограничивается
максимальной емкостью системы. Кроме того, повышение требований в одной
части монолита требует масштабирования всей системы. Разбиение монолитных
приложений на микросервисы поможет преодолеть проблемы масштабирования
и справиться с нагрузкой.
Помимо обслуживания программного обеспечения, унаследованные приложения дорого обходятся для аппаратной инфраструктуры, так как они работают
на конкретных версиях. Они распределяются по нескольким базам данных
с дублированием данных и сходной функциональности. Ввиду их монолитной
природы это усложняет консолидацию и использование гибких возможностей
облачных инфраструктур для экономии затрат. Кроме того, децентрализация
систем позволяет командам разработчиков выбирать программные стеки на
основании потребностей отдельных микросервисов и не привязываться к одному технологическому стеку для всей системной функциональности. Можно
применять разные технологии в зависимости от потребностей каждого микросервиса и/или команды, занимающейся его поддержкой.
Рассмотрим теперь некоторые ключевые преимущества модернизации систем.
Определение стратегии модернизации
Часто унаследованные системы выпадают из общей корпоративной стратегии
цифровой трансформации, а проблемы решаются по мере их возникновения.
Такой подход лишает организации возможности провести общую модернизацию
и воспользоваться ее преимуществами.
Если унаследованная система создает серьезные препятствия для бизнеса (например, в области безопасности или комплаенса) или не может реализовать его
потребности, можно воспользоваться методом «Большого взрыва» — то есть
построить новую систему с нуля и закрыть старую. Это рискованное решение,
но оно решает проблемы бизнес-целей, что невозможно в рамках существующей
унаследованной системы.
В другом возможном решении — поэтапном — модули обновляются по одному,
и старая, и новая системы продолжают работать параллельно. Поэтапное решение
сопряжено с меньшим риском, но занимает больше времени и может обойтись
дороже, так как придется поддерживать обе среды с повышением пропускной
способности сети и инфраструктуры.
Начать следует с анализа портфеля приложений, назначения приоритетов
конкретным приложениям и определения общего плана. При использовании
облачной платформы вы проектируете новую операционную модель, и в вашем
распоряжении оказывается набор инструментов. Можно использовать сторонние
инструменты, чтобы структурировать потребности и предпочтения в выборе
технологий. Или обратиться к консалтинговому партнеру, чтобы завершить
проекты миграции и модернизации быстрее и успешнее.
Определение стратегии модернизации
575
Каждый из этих подходов обеспечит разные преимущества по завершении модернизации приложения.
Оценка унаследованного приложения
В организации может существовать несколько унаследованных систем, насчитывающих от десятков тысяч до миллионов строк кода. Модернизация
унаследованной системы должна соответствовать бизнес-стратегии и затратам.
Возможно, какие-то части кода удастся использовать повторно или же придется переписывать их с нуля, но прежде всего необходимо провести оценку всей
системы и разобраться в ней.
y
y
y
Архитектор решений должен по возможности упростить оценку системы и принять обоснованные решения. Оценка может занять дни и недели в зависимости
от рабочей нагрузки и ее сложности. Области, которым необходимо уделить
основное внимание при проведении оценки.
y Технология: выяснить, какой технологический стек используется в системе. Если текущая технология устарела и не поддерживается поставщиком, возможно, ее придется заменить. Если доступна более современная
версия технологии, рассмотрите возможность обновления. Часто новые
версии обладают обратной совместимостью при минимуме необходимых
изменений.
y Архитектура: понять общую архитектуру, чтобы сделать ее future-proof
(защищенной от устаревания, адаптивной к будущим изменениям). Возможно, в будущем потребуется незначительно обновить технологию, но
общая архитектура должна быть более монолитной и масштабируемой.
Желательно провести аудит архитектуры в отношении затрат, масштабируемости, доступности, производительности и безопасности. Чтобы привести приложение в соответствие с бизнес-целями, могут потребоваться
значительные архитектурные изменения.
y Оценка кода и зависимостей: унаследованные системы часто содержат сотни
тысяч строк монолитного кода. Запутанные связи между модулями сильно
усложняют систему. Код, который вроде бы не используется в одном модуле,
может повлиять на другие модули, если его неосмотрительно удалить. Эти
строки кода могли быть написаны десятилетия назад и требовали регулярного
рефакторинга и рецензирования. Даже если с технологией и архитектурой
все в порядке, необходимо определить, возможно ли обновление и обслуживание кода. Также необходимо понять, потребуются ли обновления 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
y
y
y
После оценки системы необходимо понять схему существующей архитектуры
и ее ограничения. Затем оценить инструменты миграции с учетом технологического стека. Например, можно воспользоваться эмулятором для миграции
мейнфрейма или vCenter, если вы переносите приложение в VMWare. Выберите
подходящий метод модернизации и создайте подтверждение концепции (POC,
Proof of Concept) для выявления пробелов. Ниже перечислены некоторые возможные методы модернизации.
y Модернизация, управляемая архитектурой: этот метод используется для
обеспечения наибольшей адаптивности. Часто архитектурное решение
делается независимым от языка и платформы за счет применения сервисориентированных схем, что обеспечивает команде разработки гибкость
для внедрения инноваций. Вы можете выбрать этот вариант, если оценка
показывает необходимость значительных изменений архитектуры. Начните с реализации самой критической функциональности, а затем создайте
подтверждение концепции (POC), выявляющее недостатки и необходимые
усилия для их устранения. Используйте микросервисную структуру для
обеспечения масштабируемости и лучшей интеграции с другими системами
в зависимости от унаследованного приложения.
y Переработка системы (реинжиниринг): при таком подходе требуется тщательно разобраться в унаследованной системе и переработать ее в новое
модернизированное приложение. Принимайте технологические решения,
которые помогут создать future-proof систему. Этот подход применяется,
когда унаследованная система слишком сложна и требует долгосрочных
проектов. Начните с модернизации приложения и обновите базу данных последним этапом поэтапного подхода. Необходимо сформировать механизм,
в котором унаследованные и обновленные модули будут сосуществовать
в системе с возможностью гибридных взаимодействий.
y Миграция и усовершенствования: если технология существующей системы
работает относительно хорошо, но ограничивается возможностями существующего оборудования и затратами, можно выбрать вариант миграции
с небольшими усовершенствованиями. Например, перенести всю рабочую
нагрузку в облако для улучшения доступности инфраструктуры и оптимизации затрат. Кроме того, некоторые готовые инструменты облачных
провайдеров расширены и позволяют чаще вносить изменения и применять более эффективную автоматизацию. Вариант с миграцией позволяет
модернизировать приложение с меньшими усилиями и делает его futureproof, то есть адаптируемым к будущим изменениям. Однако возможности
перемещения по схеме lift-and-shift ограниченны, и оно может подходить
не для всех рабочих нагрузок.
Планируя миграцию и модернизацию, учитывайте, какие конкретные области
требуют существенной переработки и модернизации. Модернизация включает
578
Глава 15. Переработка архитектуры унаследованных систем
среды разработчиков в конкретной операционной системе, так как это влияет
на управление патчами. Затем — безопасность, сеть и управление идентификационными данными. Модернизация этих параметров — отличная возможность
для обеспечения масштабируемости, устойчивости и сокращения затрат. После
этого можно переходить к хранению, резервному копированию и инструментам
баз данных, поскольку все больше приложений перемещается в облако. Кроме
того, необходимо модернизировать инструменты мониторинга и управления,
что требует обучения и переподготовки. Рассмотрим некоторые стратегии модернизации унаследованных систем.
Преимущества модернизации систем
Создание будущей цифровой стратегии за счет удовлетворения растущей потребности в модернизации унаследованных систем имеет немало преимуществ,
как показано на рис. 15.3.
Future-proof бизнес-стратегия
Возможность использования
новейших технологий
Опережение
конкурентов
Преимущества модернизации
унаследованных систем
Надежность
и производительность
приложений
Экономичность
Удовлетворенность клиентов
Рис. 15.3. Преимущества модернизации унаследованных систем
Определение стратегии модернизации
579
y
y
y
y
y
y
Назовем основные преимущества модернизации приложений.
y Удовлетворенность клиентов: использование новейших технологий позволяет предоставить более современный пользовательский интерфейс (UI),
пользовательский опыт (UX) и омниканальные взаимодействия. Потребители привыкли получать доступ к информации в режиме реального времени
с любого устройства, в любом месте и в любое время. Не нужно создавать
разные варианты UI; интерфейс можно построить один раз и развернуть
на разных устройствах: ноутбуках, планшетах, смартфонах и т. д. Быстрый
и элегантный пользовательский интерфейс улучшает пользовательский опыт
и способствует росту бизнеса.
y Future-proof бизнес-стратегия: модернизация приложения позволяет
действовать более адаптивно и внедрять инновации. Команда может легко
адаптироваться к изменяющимся потребностям и развиваться с новой технологией.
y Опережение конкурентов: пользователи всегда стремятся к новшествам
и переходят на новые приложения, которые предоставляют более качественные взаимодействия. Модернизация приложения помогает опережать конкурентов за счет внимания к новейшим тенденциям. Например, интеграция
голоса поддерживается многими приложениями, а для повышения безопасности можно использовать распознавание лиц. Это возможно только в том
случае, если приложение использует новейшие технологии.
y Надежность и производительность приложений: каждый новый API и каждая версия операционной системы направлены на повышение производительности. Использование новейших версий программного обеспечения
и оборудования позволяет повысить производительность, масштабируемость
и доступность. Модернизация приложений способствует сокращению простоев и улучшает безопасность.
y Возможность использования новейших технологий: унаследованные
системы не позволяют получить из данных аналитическую информацию,
которая бы способствовала росту бизнеса. Проведя модернизацию базы
данных и создав озеро данных, можно использовать Big Data и МО для
получения подобной информации. Модернизация также поможет удержать специалистов, которые получат возможность поработать с новыми
технологиями.
y Экономичность: в целом любая модернизация приводит к экономии за счет
сокращения потребности в обслуживании и более естественного обновления.
Применение программ с открытым исходным кодом сокращает затраты на
лицензирование, гибкость оборудования помогает адаптировать облачную
модель оплаты по фактическому использованию, а автоматизация сокращает
количество сотрудников, необходимое для повседневной работы, и повышает
общую эффективность.
580
Глава 15. Переработка архитектуры унаследованных систем
Выполняя миграцию унаследованных базовых систем, организации могут их
модернизировать и сократить затраты на владение, автоматизировать ручные
процессы бэк-офиса, избавиться от старых хранилищ данных, улучшить взаимодействие с пользователями и ускорить запуск новых приложений, ориентированных на рынок.
Модернизация унаследованных систем имеет много преимуществ, но она
может быть очень сложной и требовать значительных усилий. Чтобы выбрать
правильную ее стратегию, необходимо тщательно проанализировать систему.
В следующем разделе рассматриваются методы модернизации унаследованных
систем.
Методы модернизации
унаследованных систем
В зависимости от анализа существующих приложений можно выбрать разные
способы обновления унаследованных систем. Самый простой вариант — миграция и рехостинг — не требует изменения существующей системы. С другой
стороны, простая миграция может не решить долгосрочных проблем или не дать
ощутимые преимущества.
Можно выбрать более сложный путь — такой, как изменение архитектуры или
перепроектирование всего приложения, если система перестает удовлетворять
потребностям бизнеса. На рис. 15.4 представлены последствия выбора разных
методов модернизации.
Рефакторинг и изменение архитектуры
Технология и последствия
Объем работы и сложность
Инкапсуляция, рехостинг и смена платформы
Перепроектирование и замена
Рис. 15.4. Методы модернизации унаследованных систем
Ниже кратко описаны методы модернизации, представленные на этой диаграмме.
Методы модернизации унаследованных систем
581
Инкапсуляция, рехостинг и смена платформы
Инкапсуляция — самый простой подход. Если система критически важна для
ведения бизнеса и должна взаимодействовать с другими приложениями, работающими с использованием новейших технологий, используйте этот метод.
Для инкапсуляции необходимо создать API-обертку унаследованной системы,
чтобы другие бизнес-приложения могли с этой системой взаимодействовать.
API-обертка часто используется, когда приложения переносят в облако, но
сохраняют унаследованную версию в локальном дата-центре для модернизации на следующем этапе. Можно выбрать вариант с инкапсуляцией, если
унаследованный код качественный и его легко обслуживать, но еще раз
напомним, что это не даст преимуществ использования новых технологий
и гибкости оборудования.
Рехостинг — одна из прямолинейных стратегий; приложение переносится на
оборудование другого провайдера (например, в облако AWS) без изменений кода.
И снова, как и в случае с инкапсуляцией, рехостинг может сократить затраты
благодаря контракту с провайдером, но не даст преимуществ использования
новых технологий и гибкости оборудования.
Организации часто применяют этот подход, когда им нужно быстро выйти из
существующего контракта. Например, можно начать с перемещения в облако
и провести модернизацию вторым этапом.
Смена платформы может быть более сложной, чем рехостинг, но она даст немедленные преимущества. Организации часто выбирают этот подход, если
срок жизни сервера завершается, поддержка отсутствует или для решения проблем безопасности требуется обновление системы. Например, если поддержка
Windows Server 2012 завершается, рассмотрите возможность обновления ОС
до версии Windows Server 2022. Необходимо будет переконфигурировать
двоичные файлы для новой операционной системы и провести тестирование,
чтобы убедиться, что все работает нормально, но сильно менять код не придется.
И снова, как и в случае с рехостингом, смена платформы не даст преимущества
новых технологий. С другой стороны, это позволит пользоваться непрерывной
поддержкой поставщика.
Хотя три перечисленных варианта просты, некоторые преимущества обновления
при их выборе останутся недоступными. Рассмотрим еще одно решение, которое
позволит воспользоваться всеми преимуществами модернизации.
Рефакторинг и переработка архитектуры
Рефакторинг — это адаптация кода для новой системы. Общая архитектура
при этом остается неизменной, но код обновляется, чтобы соответствовать
новейшим возможностям языка программирования и версии операционной
системы. Можно провести рефакторинг части кода, чтобы применить автоматизацию и расширить функциональность. Если используемая технология все
582
Глава 15. Переработка архитектуры унаследованных систем
еще актуальна и может удовлетворить потребности бизнеса при изменении кода,
выбирайте этот вариант.
Переработка архитектуры подразумевает изменение архитектуры системы
с повторным использованием существующего кода, насколько это возможно. Например, можно создать из монолитной архитектуры архитектуру микросервисов.
Можно брать по одному модулю и преобразовывать его в сервис-ориентированную архитектуру, назначая каждому модулю эндпоинт RESTful. Переработка
архитектуры позволяет достичь желаемой масштабируемости и надежности; тем
не менее общая производительность может остаться на среднем уровне из-за
использования существующего кода.
Перепроектирование и замена
Решение с перепроектированием — самое сложное, но при этом дающее больше
всего преимуществ. Этот подход можно выбрать в том случае, если унаследованная система не может обеспечить потребности бизнеса и ее необходимо
обновить. При перепроектировании приходится строить всю систему с нуля,
сохраняя масштаб решения.
На рис. 15.5 представлена схема миграции унаследованной системы на базе
мейнфрейма в облако AWS.
Облако AWS
Корпоративный дата-центр
Унаследованная
операцииооная система
Amazon API
Gateway
Унаследованное оборудование
Пакетная
подсистема
База данных
Файлы данных
Безопасность
Анализ
Менеджер
транзакций
Модель
приложения
Авторефакторинг
COBOL, PL/I, RPG, C, Assembler
вычисления
Amazon EC2
Очереди
Amazon SQS
контейнеры микросервисы
Amazon EKS AWS Lambda
Мониторинг Планировщик
база данных
Amazon Aurora
AWS Firewall
Manager
AWS WAF
Рис. 15.5. Модернизация унаследованной системы на базе мейнфрейма в облако
Для унаследованной системы на базе мейнфрейма производятся переработка
архитектуры и рефакторинг с перемещением в аналогичные облачные сервисы.
Ориентированность на облако позволяет использовать весь потенциал облачных
сервисов в отношении масштабируемости, производительности, надежности
и затрат. Это повысит адаптивность и инновационность команды за счет внедрения быстро изменяющейся технологии. Стратегии и преимущества облачной
Определение стратегии облачной миграции для унаследованных систем
583
миграции рассматривались в главе 3 «Миграция на облачные платформы и проектирование облачных архитектур».
Перепроектирование унаследованной системы требует долгосрочного проекта, подразумевающего значительный объем работы и высокие затраты.
Прежде чем запускать модернизацию, архитектор решений должен тщательно
проверить, не справится ли с потребностями бизнеса какой-либо продукт
SaaS или коммерческий готовый продукт при меньших затратах. Прежде
чем браться за перепроектирование, следует провести сравнительный анализ
экономической эффективности (cost-benefit analysis, CBA) перепроектирования и покупки.
Иногда выгоднее заменить устаревшую систему новым сторонним продуктом.
Например, в организации сохранилась система 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-версию продукта и выведите из эксплуатации унаследованное приложение. Возможно, вы
захотите сохранить унаследованную систему в локальном дата-центре, если
она участвует во многих бизнес-зависимостях и ее нельзя переместить в облако
из-за несовместимости.
Проведите анализ суммарной стоимости владения (TCO, Total Cost of
Ownership), чтобы понять преимущества перехода в облако. TCO включает
ряд составляющих.
Определение стратегии облачной миграции для унаследованных систем
585
y
y Затраты на инфраструктуру: сравните затраты на локальную инфраструк-
y
y
y
y
y
туру, включая серверы, хранилища, сети и дата-центры, с затратами на облачные сервисы.
y Затраты на обслуживание и администрирование: включите в расчет затраты, связанные с обслуживанием и управлением локальной инфраструктуры
(например, зарплаты IT-персонала), относительно управляемых сервисов
в облаке, сокращающих потребность во внутреннем управлении.
y Масштабирование и гибкость: оцените финансовые последствия от способности облака масштабировать ресурсы по возрастанию или убыванию в зависимости от потребности, что может привести к экономии по сравнению
с фиксированными расходами на локальную инфраструктуру.
y Затраты на лицензирование и подписку: сравните затраты на лицензии ПО
и подписки на облачные сервисы.
y Затраты на миграцию: примите во внимание одноразовые затраты на миграцию рабочих нагрузок в облако, включая затраты на перемещение данных,
оснащение и потенциальное время простоя.
y Безопасность и комплаенс: оцените затраты, связанные с достижением
и поддержанием безопасности и комплаенса — как в локальной, так и в облачной среде.
До начала миграции рекомендуется взять самый сложный модуль унаследованного приложения и сформировать подтверждение концепции (POC), чтобы
убедиться, что вся система будет совместимой с облачной платформой. Подробная формулировка POC, охватывающая критически важные бизнес-сценарии,
поможет выявить недочеты и значительно сократить риски во время миграции.
При оценке облачной совместимости следует учитывать ряд ключевых факторов. Сначала оцените соответствие архитектуры и убедитесь, что структура
приложения соответствует таким облачным принципам, как масштабируемость,
устойчивость и слабая связанность. Затем выявите любые зависимости от конкретного оборудования или локальных ресурсов, облачная поддержка которых
может быть неоптимальной. Также очень важно, чтобы облачная среда была
способна удовлетворять требования приложения к производительности с учетом таких факторов, как сетевая задержка и доступность ресурсов. Кроме того,
убедитесь, что требования к безопасности приложения и комплаенсу полностью
удовлетворяются в облачной среде. Наконец, оцените экономическую эффективность миграции в облако и убедитесь, что миграция соответствует финансовым
целям организации. Такой комплексный подход помогает определить, насколько
хорошо приложение подходит для облачной среды, и упрощает принятие обоснованных решений о миграции.
Документация и поддержка — важнейшие элементы любого обслуживания.
В следующем разделе они рассматриваются более подробно.
586
Глава 15. Переработка архитектуры унаследованных систем
Документация и поддержка
Подготовьте необходимую документацию и мероприятия поддержки для обес
печения долговременной работоспособности новой системы и корректной миграции на нее. Предоставьте документацию по принятым стандартам кодинга,
чтобы все могли им следовать; это поможет поддерживать актуальность новой
системы. Храните документы, касающиеся архитектуры, как рабочие артефакты,
обновляя их с изменением технологий. Поддержание актуальности системы
поможет избежать повторения ситуации с модернизацией унаследованных
решений.
Подготовьте подробные инструкции по поддержке старых и новых систем.
Старую систему можно оставить на некоторое время, пока новая не будет удо
влетворять всем бизнес-требованиям и работать как следует. Обновляйте ранбук
по поддержке и следите, чтобы информация не терялась из-за оттока персонала,
а в основе работы с общей базой знаний не лежал человеческий фактор.
Отслеживание зависимостей системы поможет определить влияние любых
будущих изменений. Вы больше узнаете о документации из главы 16 «Документирование архитектуры решений». Подготовьте контент для обучения персонала
работе с новой системой и убедитесь, что поддержка системы будет возможна
даже при операционных сбоях.
Мейнфреймы — один из вариантов унаследованных рабочих нагрузок, которые
продолжают работать локально во многих организациях. В следующем разделе
рассматривается их миграция на облачные платформы.
Миграция мейнфреймов на публичные
облачные платформы
Многие предприятия переносят свои рабочие нагрузки на мейнфреймах в облако,
чтобы воспользоваться преимуществами экономичности, повышенной адаптивности, сокращения технического долга, поддержки цифровой трансформации
и аналитики данных, а также чтобы справиться с нехваткой квалифицированных
специалистов по старым мейнфреймам. Миграция мейнфреймовых рабочих
нагрузок проблемнее, чем миграция рабочих нагрузок на базе x86, поскольку
унаследованные приложения для мейнфреймов часто имеют сильную связанность. Например, они могут включать программы, используемые несколькими
подсистемами или напрямую вызываемые другими приложениями. В таких
случаях изменения этих программ повлияют на связанные подсистемы и приложения.
Переход с мейнфрейма в облако открывает уникальную возможность для
будущей работы, хотя облачные провайдеры могут не поддерживать точную
аппаратную архитектуру мейнфрейма. Для организаций такой переход подразу
мевает стратегические решения: они могут эмулировать среду мейнфрейма на
Миграция мейнфреймов на публичные облачные платформы
587
платформах x86 или же провести рефакторинг приложений для совместимости
с x86. Хотя рефакторинг требует более значительных исходных вложений, он
открывает путь к масштабируемости приложения в облаке, что в итоге соответствует целям цифровой трансформации и инновационности.
Для унаследованных приложений лучшей практикой является инкрементный
подход, при котором миграция планируется в виде волн. Этот подход помогает
сократить риски, так как приоритеты назначаются тесно связанным приложениям, чтобы они проходили миграцию вместе. Однако иногда он может оказаться
более сложным, поскольку в коде приложений для мейнфреймов может присутствовать связанность во времени (синхронный вызов) или развертывании
(связанные модули).
Рассмотрим некоторые специфические сложности, возникающие при миграции
мейнфреймов.
Проблемы модернизации мейнфреймов
y
y
y
y
y
y
Модернизация мейнфреймов сталкивается с рядом специфических проблем,
вызванных масштабом и сложностью мейнфреймов, а также важностью приложений, которые на них часто выполняются. Такие системы нередко используют
устаревшие языки программирования, содержат неочевидные и недокументированные зависимости и требуют особых знаний и навыков, которые встречаются
все реже. Перечислим некоторые из таких проблем.
y Устаревшие языки программирования: мейнфреймы часто используют
унаследованный код, написанный на старых языках, на освоение которых
современному профессионалу потребуется время.
y Сложные системные зависимости: многие приложения для мейнфреймов
десятилетиями развивались и обрастали неочевидными недокументированными зависимостями, которые трудно распутать и модернизировать без
нарушения функциональности.
y Необходимость специальных знаний: квалификация, необходимая для
работы с системами на базе мейнфреймов и их обслуживания, встречается
все реже, так как работники с соответствующим опытом выходят на пенсию.
y Целостность и безопасность данных: в процессе модернизации существует
критическая необходимость в поддержании целостности и безопасности
данных, что может быть непросто при переходе из закрытой, безопасной
среды мейнфрейма в более открытую систему.
y Риски для непрерывности операций: мейнфреймы обычно управляют
важнейшими бизнес-операциями. Необходимо тщательно планировать модернизацию, чтобы не нарушить работоспособность процессов, критически
важных для бизнеса.
y Интеграция с современными технологиями: интеграция приложений для
мейнфреймов с более новыми сервисами и технологиями на базе облака
588
Глава 15. Переработка архитектуры унаследованных систем
y
y
y
y
может быть затруднена из-за различий в архитектурах и коммуникационных
протоколах.
y Трудности с масштабированием: приложения для мейнфреймов, часто не
рассчитанные на горизонтальное масштабирование, переносятся в современные облачные среды, в которых эластичное масштабирование является
нормой.
y Высокие расходы: финансовые вложения, необходимые для модернизации,
могут быть довольно значительными, особенно в краткосрочной перспективе.
y Последствия для производительности: производительность модернизированных систем должна быть такой же, как у высокооптимизированных систем
на базе мейнфреймов, или выше.
y Сопротивление внутри организации: возможно, вам придется преодолеть
сопротивление внутри организации, так как системы на базе мейнфреймов
глубоко внедрились в повседневную культуру компании и стейкхолдеры,
привыкшие к существующим системам, должны принять изменения.
Обеспечение безопасности и целостности данных при переходе также создает
серьезные проблемы, как и риск нарушения бизнес-процессов, — ведь мейнфреймы обычно обеспечивают выполнение основных бизнес-операций.
Миграция кода приложений с большим количеством связей влияет на зависимые
приложения и создает риски. Чтобы сократить эти риски, необходимо ослабить
связи кода приложения на базе мейнфрейма без последствий для зависимых
приложений. С точки зрения миграции кода можно выделить два основных типа
унаследованных приложений на базе мейнфреймов: автономные приложения
и приложения с совместно используемым кодом. Рассмотрим схемы миграции
для каждого из этих типов более подробно.
Миграция автономных приложений
Допустим, имеются два автономных приложения, A и B, на базе мейнфреймов.
Каждое приложение состоит из программ и подпрограмм, которые оно использует монопольно.
Так как приложения автономны, можно сгруппировать их программы и подпрограммы COBOL для рефакторинга, как показано на рис. 15.7.
На этой диаграмме программы и подпрограммы на мейнфрейме написаны на
COBOL, и код мигрирует на Java в AWS. Впрочем, эти паттерны ослабления
связей подойдут для любого языка программирования. Миграция выполняется
посредством автоматического рефакторинга унаследованной системы, при котором код, данные и зависимости автоматически преобразуются на современный
язык, хранилище данных и фреймворк, с гарантиями функциональной эквивалентности. Рефакторинг подразумевает использование автоматизированных
инструментов для перевода языка программирования мейнфрейма (такого, как
COBOL) на современный язык (например, Java или .NET).
Миграция мейнфреймов на публичные облачные платформы
Локальный мейнфрейм
589
Облако AWS
Приложение A
AWS Fargate
Библиотека
программ COBOL
Программы Java
Программа A
Программа A
Приложение B
AWS Fargate
Библиотека
программ COBOL
Программы Java
Программа B
Программа B
Приложение A
Приложение B
Рис. 15.7. Модернизация мейнфреймов для автономных приложений
Приложения, прошедшие рефакторинг, развертываются в контейнерах под
управлением AWS Fargate. Fargate — бессерверное вычислительное ядро для
контейнеров, работающее как с Amazon ECS (Elastic Container Service), так
и с Amazon EKS (Elastic Kubernetes Service). В данном случае таблицы базы
данных и файлы с мейнфрейма переносятся с приложением.
После группировки можно провести миграцию приложений A и B в одной или
разных волнах. В любом случае современные компоненты каждого приложения,
полученные в результате рефакторинга, упаковываются и развертываются совместно в среде выполнения. После миграции надо вывести из эксплуатации
локальные приложения на базе мейнфрейма и их компоненты. Рассмотрим
более сложные сценарии, в которых код может использоваться несколькими
приложениями.
Миграция приложений с совместно используемым кодом
Представим, что приложения A и B на базе мейнфреймов запускают общий
код — назовем его программой AB. Необходимо провести импакт-анализ (оценку
последствий изменений) общей программы AB, чтобы переносить приложения A,
B и программу AB вместе. На основании импакт-анализа определяются зависимые приложения, использующие общие программы (такие, как AB). Необходимо
590
Глава 15. Переработка архитектуры унаследованных систем
провести анализ бизнес-области и установить, можно ли объединить общую
программу в одну область с приложениями, чтобы предоставлять доступ к ней
через API как к одному из сервисов.
Рассмотрим, какие действия можно предпринять для ослабления связей между
приложениями в процессе подготовки к миграции.
Ослабление связей между приложениями с использованием
автономного API
Используя этот способ, можно создать автономный API, преобразовав общую
программу на COBOL в программу Java. Можно применить имеющиеся инструменты автоматизированного рефакторинга, чтобы сгенерировать сетевые
API для программы; тем самым усилия по рефакторингу будут сведены к минимуму. Этот подход рекомендуется выбирать, когда общая программа может
быть инстанцирована в виде автономного сервиса. Остальные компоненты
приложений A и B переводятся на Java и переносятся в облако. Приложения
можно мигрировать в одной волне, как показано на рис. 15.8.
Облако AWS
Локальный мейнфрейм
Приложение A
AWS Fargate
Библиотека
программ COBOL
Приложение A
Программы Java
Программа A
REST
Программа AB
Приложение B
Программа AB
AWS Fargate
Библиотека
программ COBOL
Программы Java
Программа B
Программа B
Вызовы API
Приложение B
Рис. 15.8. Миграция приложений с общими программами
с помощью автономных API
Миграция мейнфреймов на публичные облачные платформы
591
При таком подходе необходимо провести рефакторинг обоих приложений
с соответствующими программами и перенести их на облачную платформу.
Используйте отчет об импакт-анализе, чтобы помочь разработчикам и командам найти приложения, прошедшие рефакторинг, которые вызывают общую
программу AB. Замените внутренний вызов программы вызовами сетевых API
к общей программе AB. После миграции выведите из эксплуатации локальные
приложения на мейнфреймах вместе с их компонентами.
Ослабление связей в приложениях с использованием
общей библиотеки
В этом варианте общая программа AB преобразуется в стандартную библиотеку
Java и упаковывается вместе с приложениями, участвующими в миграции. Используйте этот метод, когда общая программа представляет собой вспомогательную библиотеку, а не автономный сервис. Остальные компоненты приложений
A и B преобразуются в программы Java и переносятся в облако.
При таком подходе приложения A и B вместе со связанными программами
переводятся на Java и переносятся в облако. Исходный код приложений должен
поддерживаться в полностью управляемом сервисе контроля версий — например,
AWS CodeCommit. Команды, использующие общую программу, могут сотрудничать в отношении изменений кода, через пул-реквесты, ветвление и слияние,
и управлять изменениями, вносимыми в код общей программы. После миграции
выведите из эксплуатации локальные приложения на мейнфреймах вместе с их
компонентами.
Если приложения слишком велики, чтобы их можно было сгруппировать в одной волне миграции, можно провести миграцию за несколько волн, обеспечивая в ее ходе непрерывность сервиса. При таком подходе приложения можно
модернизировать по этапам без группировки. Миграция приложений в разных
волнах ослабляет связи между ними, не требуя значительных изменений кода
на мейнфрейме.
Ослабление связей в приложениях с использованием
очередей сообщений
В этом варианте общая программа AB преобразуется в программу Java и переносится в облако как часть приложения A. Очередь сообщений используется
как интерфейс между приложением, прошедшим рефакторинг, в облаке и локальным унаследованным приложением. Этот подход позволяет разбить сильно
связанные приложения на базе мейнфрейма на производители и потребители
и сделать их модульными для независимого функционирования. Дополнительное
преимущество заключается в том, что миграцию приложений можно проводить
в разных волнах.
592
Глава 15. Переработка архитектуры унаследованных систем
Этот подход можно выбрать, когда приложения на мейнфрейме могут взаимо
действовать с приложениями в облаке, прошедшими миграцию, через очередь сообщений. Желательно убедиться, что архитектурный паттерн очереди
удовлетворяет бизнес-требованиям для приложений на мейнфрейме, поскольку
он подразумевает переработку архитектуры существующих приложений.
Выбирайте решение с очередью сообщений, если для облачной миграции приложений, не входящих в первую волну, требуется много времени (полгода и более).
Если приложения слишком велики для группировки в одну волну миграции,
можно провести их миграцию за несколько волн, как показано на рис. 15.9, и сохранить непрерывность сервиса в процессе миграции.
Локальный мейнфрейм
Облако AWS
Приложение B
AWS Fargate
Библиотека
программ COBOL
Программа-посредник
AB для получения/
отправки сообщений
приложением
Очередь сообщений
Сообще- Сообщение
ние
Программа A
Программы Java
Программа A
Программа B
Рис. 15.9. Миграция приложений с общими программами с использованием
очереди сообщений
Как показано на рис. 15.9, процедура миграции состоит из следующих шагов.
1. Миграция (рефакторинг) приложения A вместе с его сопутствующими
программами на облачную платформу; приложение B продолжает работать
в локальной среде.
2. Рефакторинг приложения A (в облаке) для взаимодействия с приложением B
(локального) через очередь сообщений.
3. Рефакторинг приложения B в локальной среде для замены общей программы программой-посредником, которая отправляет и получает сообщения от
приложения A через очередь сообщений.
4. Вывод из эксплуатации локального приложения A вместе с компонентами
(включая общую программу) после успешной миграции приложения A. Приложение B и его компоненты продолжают существовать локально.
Миграция мейнфреймов на публичные облачные платформы
593
5. В следующей серии волн миграции проводится миграция приложения B
и его компонентов. Слабосвязанная архитектура очереди продолжает обес
печивать взаимодействие между приложениями A и B в облаке. Таким образом сокращаются усилия по рефакторингу приложения B без влияния на
приложение A.
Рекомендуется провести анализ кода, построить карту зависимостей для приложений на мейнфрейме и составить список программ, совместно используемых
приложениями. После этого сгруппировать приложения, использующие одни
и те же программы для одной волны миграции, чтобы сократить количество вызовов программ между локальной и облачной средой. На стадии планирования
проведите импакт-анализ, чтобы определить приложения, использующие общие
программы с приложением, для которого планируется миграция.
В этом разделе в качестве примера для модернизации мейнфреймов используется платформа AWS. В следующем разделе подробнее рассматриваются преимущества публичных облачных платформ для модернизации мейнфреймов.
Преимущества использования публичной облачной
платформы для модернизации мейнфреймов
y
y
y
Использование публичных облачных платформ для модернизации мейнфреймов имеет целый ряд преимуществ, включая улучшенную масштабируемость,
гибкость и экономичность. Облачная модель оплаты по фактическому использованию сокращает капитальные затраты, а расширенная функциональность
упрощает инновации, особенно в таких областях, как ИИ, МО и аналитика.
Облачные среды также предоставляют улучшенные средства восстановления
при сбоях и возможность перепроектировать приложения для большей устойчивости и способности адаптироваться к потребностям бизнеса. Рассмотрим
некоторые ключевые преимущества миграции рабочей нагрузки мейнфреймов
на облачные платформы.
y Улучшенная масштабируемость: облачные платформы могут автоматически
регулировать ресурсы для обработки выбросов рабочей нагрузки — в отличие от мейнфреймов, требующих ручного масштабирования. Например,
сайт интернет-магазина сможет справиться с пиковым трафиком во время
праздничных распродаж без простоев.
y Экономичность: с облачной моделью оплаты по фактическому использованию компании избавляются от высоких исходных затрат на оборудование
и обслуживание. Например, стартапы могут запускать новые приложения без
вложений в дорогостоящую инфраструктуру на базе мейнфреймов.
y Гибкость и адаптивность: облачные сервисы позволяют компаниям быстро
проводить эксперименты и развертывать новые приложения. Например,
компания может оперативно протестировать новое приложение для поддержки клиентов на разных рынках без длительного процесса подготовки.
594
Глава 15. Переработка архитектуры унаследованных систем
y
y Ускорение инноваций: облачные провайдеры предоставляют передовые
y
y
y
y
y
y
y
y
инструменты ИИ, МО и аналитики. Компания розничной торговли может
воспользоваться этими инструментами для анализа потребительских данных
и персонализации маркетинговых стратегий, что невозможно на традиционном мейнфрейме.
y Улучшенное восстановление после сбоев: облачные платформы имеют
встроенные решения избыточности и резервного копирования. Например,
финансовая компания может обеспечить непрерывность операций и целостность данных даже при стихийном бедствии.
y Оптимизация ресурсов: облачные платформы позволяют более эффективно
использовать вычислительные ресурсы. Компания может запускать приложения в облаке только в случае необходимости, что сокращает простои
вычислительных ресурсов, типичные для сред мейнфреймов.
y Ускоренный выход на рынок: адаптивность облачных средств сокращает цикл
разработки. Компания-разработчик мобильных приложений может быстро
развертывать и обновлять приложения, оставаясь впереди конкурентов.
Глобальный
охват: облачные сервисы с дата-центрами по всему миру поy
зволяют компаниям развертывать приложения рядом с пользователями.
Например, стриминговый сервис с их помощью может предоставлять контент
с низкой задержкой пользователям со всего мира.
y Улучшенные средства безопасности: крупные облачные провайдеры вкладывают значительные средства в кибербезопасность. Это означает, что небольшая компания может пользоваться теми же преимуществами средств
безопасности, что и крупные корпорации, чего достаточно трудно достичь
с локальными мейнфреймами.
y Упрощение интеграции с современными технологиями: облачные технологии
упрощают интеграцию с современными приложениями и сервисами. Например, медицинская организация может интегрировать облачные инструменты
диагностики на базе ИИ со своей системой управления пациентами — в среде
мейнфрейма это было бы слишком сложно и ресурсоемко.
AWS предоставляет платформу M2 (Mainframe Modernization), предназначенную
для миграции и модернизации локальных приложений на базе мейнфреймов
в облачно-ориентированную, полностью управляемую среду выполнения в AWS.
Перечислим основные преимущества платформы AWS M2.
y Автоматизированный рефакторинг: преобразует унаследованные приложения на устаревших языках в адаптивные сервисы на базе Java, использующие
AWS Blu Age, соответствующие современным веб-фреймворкам и лучшим
практикам облачных процессов DevOps.
y Смена платформы: миграция приложений, написанных на COBOL, выполняется с использованием интегрированного инструментария Micro Focus, с модернизацией инфраструктуры, но при сохранении языка программирования,
обеспечивая адаптивность с облачно-ориентированными операциями DevOps.
Модернизация унаследованного кода с помощью GenAI
595
y
y Репликация данных и передача файлов: функциональность мейнфреймов
y
улучшается благодаря выполняемой практически в реальном времени репликации данных в Precisely и средствам передачи файлов BMC Software.
y Тестирование приложений: автоматизирует проверку модернизированных
приложений на базе мейнфрейма, сокращая расходы и ускоряя тестирование
за счет использования масштабируемого облачно-ориентированного сервиса.
Этот сервис сочетается с растущей потребностью в модернизации унаследованных систем, предоставляя полноценное решение для компаний, переходящих
с традиционной инфраструктуры мейнфрейма на более адаптивные и экономичные облачные среды. Узнать больше можно на странице 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,
которая призвана удовлетворить потребности всех стейкхолдеров, связанные
с разработкой приложения.
y
y
y
y
y
y
Вы узнаете о структуре SAD и других типах документов, о которых должен знать
архитектор решений, — таких, как запрос предложений (request for proposal,
RFP), где архитектору необходимо предоставить вводные данные для принятия
стратегических решений. Чтобы лучше разобраться в документе по архитектуре
решения, рассмотрим следующие темы.
y Назначение SAD.
y Представления (views) SAD.
y Структура SAD.
y Жизненный цикл SAD.
y Лучшие практики и типичные ловушки SAD.
y Документация на закупки для архитектуры решения.
К концу главы вы будете знать о документе по архитектуре решения, его структуре и деталях, которые он должен содержать. Вы узнаете о видах документации
на приобретение (запрос на предложение, запрос информации, запрос цены
и т. д.), к составлению которой архитектор решений привлекается как поставщик
обратной связи. Начнем с основ, а именно — с назначения SAD.
Назначение SAD
599
Назначение SAD
Зачастую потребности в документации на архитектуру игнорируются и команды
начинают работать над реализацией без общего понимания архитектуры. SAD
содержит общее представление всей архитектуры решения в целях информирования всех стейкхолдеров. Он важен для многих стейкхолдеров, включая
руководителей проектов, которые полагаются на этот документ при координировании и отслеживании прогресса проекта. Бизнес-аналитики используют
SAD для совмещения проекта с требованиями бизнеса. Технические команды,
включая разработчиков и IT-специалистов, обращаются к SAD при реализации
и обслуживании предлагаемых решений. Старший менеджмент использует
этот документ для принятия обоснованных стратегических решений. Наконец,
клиенты или конечные пользователи, на которых и рассчитан продукт, тоже
зависят от SAD — он гарантирует, что результат проекта будет соответствовать
их потребностям и ожиданиям.
y
y
y
y
y
y
SAD решает следующие задачи:
y распространение информации о комплексном решении между всеми ключевыми участниками;
y высокоуровневый обзор архитектуры и представлений структуры решения
для удовлетворения требований к качеству сервиса (надежность, безопасность, производительность, масштабируемость);
y обеспечение соответствия решения бизнес-требованиям и знания о том, как
приложение будет удовлетворять всем функциональным (ФТ) и нефункцио
нальным (НФТ) требованиям;
y описание всех представлений решения, необходимых для проектирования,
построения, тестирования и реализации;
y определение последствий решения для целей оценки, планирования и поставки;
y определение бизнес-процесса, длительности и операций, необходимых для
бесперерывной работы решения после запуска продукта.
SAD определяет цель и назначение решения. В нем упоминаются такие критически важные компоненты, как ограничения, предположения и риски, о которых
часто забывает команда реализации. Архитектор решений должен следить, чтобы
документ был написан простым языком, понятным для бизнес-пользователей,
и бизнес-контекст в нем должен быть соотнесен с техническим дизайном. Документ помогает сохранить информацию на случай ухода специалистов и снижает
зависимость проектирования от человеческого фактора.
Для приложений, требующих модернизации, SAD содержит абстрактное представление текущей и будущей архитектуры, а также план перехода. Архитектор
решений понимает зависимости существующей системы и документирует их,
чтобы заранее избежать потенциальных рисков. План миграции помогает бизнесу
600
Глава 16. Документирование архитектуры решений
выбрать инструменты и технологии, необходимые для запуска новой системы,
и соответствующим образом спланировать ресурсы.
Архитектор решений в процессе проектирования проводит различные оценки,
создавая подтверждение концепции (POC) или проводя исследования рынка.
В SAD должны быть перечислены все оценки архитектуры и их влияние, а также
подходящие варианты технологий. SAD содержит концептуальное представление
текущего и целевого состояний архитектуры решения, а также историю изменений. В следующем разделе рассматриваются варианты представлений SAD.
Представления SAD
Архитектор решений должен разработать SAD, понятный как для бизнеса, так
и для технических пользователей. SAD служит промежуточным звеном в коммуникации между бизнес-пользователями и командой разработки, обеспечивающим
понимание функций приложения в целом. Лучший способ воспринять входную
информацию от всех стейкхолдеров — поставить себя на их место и взглянуть
на задачи с их точки зрения. Архитектор решений оценивает параметры проектирования архитектуры со стороны как технологий, так и бизнеса и учитывает
все технические и нетехнические требования пользователей.
Как показано на рис. 16.1, общая структура SAD включает представления (views)
различных параметров, обусловленных бизнес-требованиями.
Операционное
представление
Представление
данных
Бизнеспредставление
Логическое
представление
Представления
SAD
Процессное
представление
Представление
реализации
Представление
развертывания
Рис. 16.1. Представления SAD
Представления SAD
601
y
y
y
y
Для описания различных представлений архитектор решений может выбрать
стандартные диаграммы — например, диаграммы UML (Unified Modeling
Language) или блоковые диаграммы из Microsoft Visio. Эти популярные инструменты помогают передавать сложные архитектурные концепции в доступном
формате. В целом диаграмма должна быть удобочитаемой и понятной для всех
стейкхолдеров со стороны бизнеса и технологий. SAD должен по возможности
включать следующие представления для потребностей всех сторон.
y Бизнес-представление: проектирование архитектуры учитывает потребности бизнеса и направлено на решение бизнес-задач. Бизнес-представление
показывает ценностное предложение решения и продукта. Чтобы упростить
задачу, архитектор решений может выявить высокоуровневые сценарии, относящиеся к бизнесу, и представить их в виде диаграммы юзкейсов. Бизнеспредставление также описывает стейкхолдеров и ресурсы, необходимые для
исполнения проекта. Бизнес-представление также можно рассматривать как
представление сценариев использования (юзкейсов).
y Логическое представление: описывает различные пакеты системы, чтобы
бизнес-пользователи и дизайнеры системы понимали, из каких логических
компонентов она состоит. Логическое представление предлагает упорядоченное по времени описание создания системы. Оно показывает, как системные
пакеты соединяются между собой и как пользователь может взаимодействовать с ними. Например, в банковском приложении пользователь сначала
должен пройти аутентификацию и авторизацию с использованием пакета
безопасности, получить доступ к счету с использованием пакета счетов,
подать заявку на кредит с использованием пакета кредитов и т. д. Каждый
пакет представляет собой отдельный модуль и может быть построен в форме
микросервиса.
y Процессное представление: подробнее показывает, как критически важные
процессы системы взаимодействуют друг с другом. Для него можно использовать диаграмму состояния. Чтобы раскрыть подробности, архитектор решений
может создать диаграмму последовательности. В банковском приложении
процессное представление может касаться процесса утверждения заявки на
кредит или предоставления доступа к счету.
y Представление развертывания: показывает, как приложение будет функцио
нировать в продакшен-среде. Оно демонстрирует соединения компонентов
системы (таких, как сетевой файрвол, балансировщик нагрузки, серверы
приложений и база данных). Для него лучше создать простую блоковую диаграмму, понятную для пользователей со стороны бизнеса. На UML-диаграмму
развертывания можно добавить больше информации, чтобы показать узлы
и зависимости между ними для технических пользователей (например,
команд разработки и DevOps). Представление развертывания описывает
физическую структуру системы.
602
Глава 16. Документирование архитектуры решений
y
y Представление реализации: занимает центральное место в SAD; описывает
y
y
архитектурные и технологические решения. Оно должно содержать архитектурную диаграмму (например, если это 3-уровневая, N-уровневая или
управляемая событиями архитектура) и обоснования выбора архитектуры.
Также будет полезно разместить подробные описания выбора технологий —
например, использования Java вместо Node.js с достоинствами и недостатками
обоих вариантов. В представлении реализации следует дать обоснование всем
ресурсам и навыкам, необходимым для выполнения проекта. Команда разработки использует представление реализации для создания детализированной
структуры (например, диаграммы классов), но включать эту информацию
в SAD необязательно.
y Представление данных: большинство приложений работает на основе
данных, поэтому представление данных играет ключевую роль. Оно показывает, как данные перемещаются между компонентами и как они хранятся.
Также представление данных может пояснять принципы безопасности
и целостности данных. Архитектор решений может использовать диаграмму сущностей и связей для демонстрации отношений между разными
таблицами и схемами базы данных. Подробнее о диаграммах сущностей
и связей см. в подразделе «Архитектура данных» раздела «Архитектура
решения» в этой главе. Представление данных также указывает на необходимые отчеты и аналитику.
y Операционное представление: объясняет, как будет осуществляться обслуживание системы после запуска. Часто здесь определяются соглашения об
уровне обслуживания (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. Выводы из POC (подтверждения
концепции)
Рис. 16.2. Структура SAD
604
Глава 16. Документирование архитектуры решений
Представленная структура SAD содержит разделы, относящиеся к разным
параметрам архитектуры решений и проектирования. Архитектор решений может добавить или удалить какие-то разделы, если это обусловлено
требованиями к проекту. Например, можно добавить вводный раздел для
описания цели и краткого резюме документа. Для проекта миграции можно
добавить подраздел с описанием существующей архитектуры, сравнением ее
с целевой и т. д.
Рассмотрим каждый раздел более подробно.
Обзор решения
Обзор решения содержит краткое, на 1–2 абзаца, описание решения. Здесь
в общих чертах описываются функциональность решения и его компоненты. Полезно будет добавить общую блоковую диаграмму, показывающую
все компоненты. На рис. 16.3 представлен обзор решения для платформы
интернет-магазина.
Клиентский заказ
Сайт/маркетплейс
для заказа
Оформление заказа
Поддержка клиентов
Данные
о наличии товара
Уведомление
об отправке
Цепочка поставок
и управление заказами
Платеж
Возврат
Доставка
Налог
Исполнение
заказа
Акции
Логистика
Уведомления
Отмена
заказа
Рис. 16.3. Обзор решения для интернет-магазина
Структура SAD
605
y
y
y
Необходимо дать простое и краткое описание каждого компонента, чтобы бизнеспользователь мог понять общую схему работы решения. Например, на диаграмме
выше типичный процесс заказа в интернет-магазине и работа цепочки поставок
изображены в упрощенном виде.
y Клиентский заказ.
Процесс начинается, когда клиент размещает заказ на сайте интернетмагазина или маркетплейса.
Поддержка клиентов играет важную роль, помогая клиентам с заказами,
отвечая на вопросы и решая проблемы, которые могут возникнуть в процессе заказа.
y Цепочка поставок и управление заказами.
Оформление заказа: после размещения заказа он регистрируется как
оформленный, что запускает процесс его исполнения.
Данные о наличии товара: система проверяет данные, чтобы убедиться,
что заказанные товары имеются в наличии.
Уведомление об отправке: после того как заказ будет обработан и готов
к отправке, система посылает уведомление — оно также может включать
информацию для клиента по отслеживанию посылки.
y Обработка заказа.
Платеж: обработка платежа клиента, включая применение любых налогов
и промокодов.
Налог: расчет и применение правильного налога на продажи в зависимости
от местоположения клиента и приобретенных товаров.
Логистика: организация доставки заказа к местоположению клиента.
Исполнение заказа: непосредственный отбор, упаковка и подготовка
к отправке заказанных товаров.
Отправка: процесс отправки заказа для доставки.
Акции: применение скидок или специальных предложений, которые могут
быть частью заказа.
Уведомления: отправка клиенту сведений о статусе заказа.
Возврат: обработка процедуры возврата, если клиент будет недоволен
покупкой или если с заказом возникли проблемы.
Отмена: обработка отмены заказа, если клиент решит отменить заказ до
его отправки.
Эти элементы обеспечивают эффективную обработку пользовательских заказов
с момента их размещения и до выполнения.
y
Затем приводится краткий обзор решения, включающий следующие подразделы.
y Цель решения: содержит краткое описание бизнес-проблемы, для которой
предназначается решение, и обоснование для построения этого решения.
В сценарии выше решение предназначено для оптимизации и автоматизации
y
y
y
y
y
y
y
y
y
y
y
y
y
y
606
Глава 16. Документирование архитектуры решений
процесса управления заказом в цепочке поставок. Описание должно разрешать бизнес-проблемы, связанные с эффективностью, точностью и удовлетворением клиентов при исполнении заказов.
Объем решения: здесь формулируется область действия предлагаемого
решения и четко описываются элементы, выходящие за его пределы. Объем
решения включает сквозную автоматизацию системы управления заказами,
от размещения заказа клиентом до уведомления об отправке. Он не включает
действия клиента после доставки — например, обработку обратной связи
или возврата.
Допущения: список всех допущений, сделанных архитектором при разработке
решения. Например, в нашем сценарии решение предполагает наличие минимальной пропускной способности сети для обработки данных в реальном
времени. Также предполагаются возможность интеграции с различными торговыми площадками и службами доставки и доступность систем цифровых
платежей для клиентов.
Ограничения: список всех бизнес-ограничений, а также ограничений, касаю
щихся технологий и ресурсов. Часто существуют отраслевые или нормативные ограничения — они также должны быть перечислены в этом разделе.
Кроме того, можно выделить риски и составить план их снижения. Решение
должно соответствовать нормативам защиты данных — таким, как GDPR
для обеспечения конфиденциальности данных клиентов в Евросоюзе или
PCI-DSS для хранения платежной информации клиентов в США. Ресурсные
ограничения включают фиксированный бюджет и сроки развертывания.
Также могут присутствовать технические ограничения, обусловленные интеграцией унаследованных систем.
Зависимости: список всех предшествующих и последующих зависимостей.
Например, сайт интернет-магазина должен взаимодействовать с почтовыми
сервисами (такими, как UPS или FedEx) для доставки посылок. Решение
зависит от складских данных реального времени для точной обработки заказов от системы управления складскими запасами. Оно требует интеграции
с платежными шлюзами для проведения финансовых транзакций.
Ключевые архитектурные решения: формулировки важных проблем и предлагаемые решения. Описание достоинств и недостатков каждого варианта
и причин выбора того или иного решения.
Для примера возьмем решение о применении облачной платформы для обес
печения масштабируемости. Она была выбрана благодаря своей способности
поддерживать изменяющиеся объемы заказов и снижать необходимые начальные капитальные вложения. Компромиссом такого решения являются
постоянные операционные расходы.
Другим решением может быть создание в первую очередь API для
интег рации. Этот подход обеспечит гибкость и простоту интеграции
Структура SAD
607
с партнер ами и сервисами. С другой стороны, он повысит сложность
управления API.
После обзора решения необходимо связать его с бизнес-контекстом. В следующем разделе рассмотрим представление бизнес-контекста более подробно.
Бизнес-контекст
y
y
y
y
y
В разделе бизнес-контекста архитектор решений должен представить общий
обзор бизнес-потенциала и требований, для которых создается решение. В этот
раздел включается только абстрактное представление требований. Подробные
требования перечисляются и описываются в отдельном документе, ссылку на
который можно предоставить в этом разделе. Он включает следующие основные
подразделы.
y Бизнес-возможности: краткое описание бизнес-возможностей, для которых
проектируется решение. Обязательно должно включать их преимущества
с указанием того, как перечисленные возможности будут удовлетворять
потребности клиентов.
y Ключевые бизнес-требования: перечисление всех ключевых бизнеспроблем, для которых предназначено решение. Следует изложить общее
представление ключевых требований и добавить ссылку на документ с их
подробным описанием.
y Ключевые бизнес-процессы: описание ключевых процессов. На рис. 16.4
изображено упрощенное представление модели бизнес-процессов приложения интернет-магазина.
y Бизнес-стейкхолдеры со стороны бизнеса: перечислите стейкхолдеров, на
которых прямо или косвенно влияет проект. К их числу относятся спонсоры,
разработчики, конечные пользователи, поставщики и партнеры.
y Нефункциональные требования (НФТ): архитекторы решений должны
уделять больше внимания НФТ, так как их часто упускают из виду бизнеспользователи и команда разработки. В целом НФТ должны включать:
масштабируемость: как приложение сможет масштабироваться при
колебаниях рабочей нагрузки? (Например, масштабирование от 1000 до
10 000 транзакций в секунду в течение дня или месяца.);
доступность и надежность: какое время простоя считается приемлемым
для доступности системы? (Например, 99,99 % доступность или 45-минутный период неработоспособности за месяц.);
производительность: какие требования предъявляются к производительности? Как система сможет справиться с нагрузкой без ущерба для
взаимодействий конечного пользователя? (Например, время загрузки
страницы каталога не должно превышать 3 секунд.);
608
Глава 16. Документирование архитектуры решений
портируемость: сможет ли приложение сразу работать на нескольких
платформах? (Например, мобильное приложение должно работать в операционных системах iOS и Android.);
емкость: с какой максимальной рабочей нагрузкой может справиться
приложение? (Например, максимальное количество пользователей, количество запросов, ожидаемое время ответа и ожидаемое время загрузки
приложения.)
Старт
Получение
заказа
Проверка
запасов
Обработка заказа
Обновление
запасов
Получение оплаты
Поставка
Отклонение
заказа
Уведомление
о необходимости
пополнения
Отправка
уведомления
Обновление статуса
заказа
Конец
Рис. 16.4. Диаграмма бизнес-процессов интернет-магазина
Структура SAD
609
Концептуальное представление архитектуры предоставляет полный обзор
системы для бизнес-стейкхолдеров и технологий. Рассмотрим концептуальное
представление более подробно.
Концептуальный обзор решения
Концептуальный обзор решения представляет диаграмму абстрактного уровня,
отражающую общую картину всего решения, включая технические и бизнеспараметры. Она служит основой для анализа и изучения компромиссов, что помогает уточнить и оптимизировать архитектуру решения в объеме, достаточном
для проектирования и реализации. На рис. 16.5 изображена концептуальная
архитектурная диаграмма интернет-магазина.
Мобильное
приложение
Сервис учетных записей
База данных
учетных записей
API GATEWAY
Сайт для
пользователей
Витрина
Приложение для точки
продаж
Сервис доставки
База данных
доставки
Сервис складских запасов
База данных
складских запасов
Рис. 16.5. Концептуальная архитектурная диаграмма интернет-магазина
На диаграмме изображено абстрактное представление важных модулей и потоков информации между ними. Концептуальная диаграмма обеспечивает
хорошее понимание общей архитектуры как для бизнес-, так и для технических
пользователей. При этом техническим пользователям необходимо больше
610
Глава 16. Документирование архитектуры решений
архитектурных деталей. В следующем разделе архитектура решения рассматривается более подробно.
Архитектура решения
В разделе архитектуры решения глубже рассматривается каждая часть архитектуры. Здесь содержатся разные представления, которые могут использоваться
технической командой при создании подробной архитектуры и работе над
реализацией. Эти представления могут быть ориентированы на другие группы
пользователей: разработчиков, инженеров инфраструктуры, инженеров DevOps,
инженеров безопасности и UX-дизайнеров.
Информационная архитектура
Этот подраздел в общих чертах описывает навигацию пользователя в приложении. Как показано на рис. 16.6, на сайте интернет-магазина для перехода
к нужной странице пользователю достаточно трех кликов.
Главная
Домой
Продукты
питания
Продукты
Игрушки
О нас
Одежда
Телефоны
Контакты
Электро- Профиль
ника
Мой профиль
Заказы
Способы
оплаты
Телевизоры
Рис. 16.6. Диаграмма информационной архитектуры интернет-магазина
Архитектор решений может добавить дополнительную информацию: нави
гацию по сайту, таксономию или высокоуровневую каркасную модель,
которая используется UX-дизайнерами для создания детализированного
вайрфрейма.
Структура SAD
611
Архитектура приложения
Этот раздел предназначен для команды разработки. Он содержит больше подробностей реализации для архитектора или команды разработки в целях создания
подробного дизайна. На рис. 16.7 изображена архитектура приложения для сайта
интернет-магазина, содержащая такие структурные элементы, как кэширование,
сети, распространение контента и хранение данных.
Облако AWS
Amazon S3 для журналов,
данных посещений
и изображений товаров
VPC
Сервис
рекомендации
товаров
Каталог
и кэш сессии
CACHE
Route 53
CACHE
Elastic Cache
Amazon
CloudFront
Запрос на покупку
и оплата через SSL
Сервис
приложения
интернет-магазина
Поисковая
система на
базе Amazon
Elasticsearch
Сервис
оформления
заказа
DynamoDB для каталога
товаров, пользовательских
профилей и хранилища
пользовательских
транзакций
Рис. 16.7. Диаграмма архитектуры приложения для интернет-магазина
y
y
y
На диаграмме необходимо перечислить компоненты архитектуры приложения,
которые нужны для обеспечения онлайн-покупок на облачной платформе интернет-магазина. К числу таких компонентов относятся следующие.
y Пользовательские взаимодействия: клиенты взаимодействуют с платформой
интернет-магазина через веб-интерфейс, начиная с безопасного размещения
заказа, совершаемого через SSL (Secure Sockets Layer) для шифрования
передачи данных.
y Поставка контента: Amazon CloudFront — сеть поставки контента (CDN) —
эффективно поставляет пользователям статический контент: графику,
таблицы стилей, клиентские скрипты. Кэширование контента рядом с местоположением пользователя сокращает задержку.
y DNS (Domain Name System): Amazon Route 53 используется для управления DNS, направляя пользовательские запросы наиболее подходящим
эндпоинтам — например, в CloudFront или балансировщику нагрузки
приложения.
612
Глава 16. Документирование архитектуры решений
y
y Обработка, выполняемая приложением: внутри виртуального частного об-
y
y
y
y
лака VPC (Virtual Private Cloud) приложение интернет-магазина обрабатывает динамические запросы — например, выполняет рендеринг страницы на
основании пользовательских профилей и истории покупок. Сервис рекомендации товаров внутри VPC предлагает персонализированные рекомендации
пользователям на основании их поведения и предпочтений.
y Механизм кэширования: Amazon ElastiCache применяется для ускорения
выборки данных за счет кэширования данных, к которым часто совершаются
обращения, — например, состояния сессии и информации часто просматриваемых товаров. Тем самым сокращаются нагрузка на базы данных бэкенда
и время реакции приложения.
y Хранение и обработка данных: сервис оформления заказов управляет взаи
модействиями пользователя с покупательской корзиной и транзакциями.
Данные кэша сессии и каталога сохраняются для быстрого доступа. Поисковая система на базе Amazon Elasticsearch предоставляет мощные средства
поиска по каталогу товаров.
y Пользовательские профили и данные транзакций: информация пользовательских профилей вместе с данными транзакций хранится в сервисе Amazon
DynamoDB, обеспечивающем быструю и масштабируемую функциональность
баз данных NoSQL.
y Журналы данных: Amazon S3 используется для хранения разного рода журнальных данных: данных посещений, взаимодействий с продуктом, системных
журналов и т. д. Это позволяет проводить углубленный анализ и извлекать
данные о поведении пользователя и эффективности системы.
В этом разделе перечисляются все модули приложения, которые следует вывести
из эксплуатации, сохранить, переместить на другую платформу или преобразовать для модернизации архитектуры.
Архитектура данных
Этот раздел в основном используют администраторы баз данных и команда разработки, чтобы понять схемы баз данных и отношения между таблицами. В него
часто включается диаграмма сущностей и связей (ERD, Entity-Relationship
Diagram), показывающая отношения между наборами сущностей, хранящимися
в базе данных (рис. 16.8).
Рис. 16.8. Диаграмма сущностей и связей для платформы интернет-магазина
Структура SAD
613
y
y
y
Диаграмма ERD содержит наглядное представление сущностей (обычно
соответствующее таблицам баз данных) и отношений между ними. Это графический инструмент, используемый при проектировании баз данных для
демонстрации их логической структуры. На рис. 16.8 показан пример ERD
для системы обработки заказов. Диаграмма демонстрирует связи между происходящими событиями и заказами, обрабатываемыми в системе. Назовем
компоненты и связи между ними.
y Сущность Event (событие): представляет собой явление или действие внутри
системы с такими атрибутами, как Event_ID (первичный ключ), Event_Type,
Event_Name и Event_Loc. Эти атрибуты могут содержать подробную информацию о том, что собой представляет событие, где оно произошло, а также
другие характеристики.
y Сущность Order (заказ): представляет собой заказ клиента с такими атрибутами, как Order_ID (первичный ключ), Order_Number (номер заказа),
Order_Type (тип заказа), Order_Quantity (количество), Order_Date (дата
заказа) и Ship_Address (адрес доставки). Эти атрибуты содержат информацию, относящуюся к каждому заказу: объем заказа, подробная информация
о доставке, дата оформления и т. д.
y Сущность Order_Processing (обработка заказа): является ассоциативной
сущностью (или таблицей соединения), связывающей Event с Order; показывает, что Event приводит к обработке Order. Имеет собственный первичный
ключ (Processing_EventID) и содержит внешние ключи Event_ID и Order_ID,
связанные с сущностями Event и Order соответственно. Присутствие атрибута
Order_Event_date указывает, что в нем хранится информация о том, когда
обрабатывается событие, приводящее к заказу.
Линии между сущностями представляют собой отношения. На этой диа
грамме ERD «птичья лапка» в конце линий отношений означает «многие»,
тогда как одиночная линия означает «один»; эти значки показывают мощность
связей.
В разделе архитектуры данных перечисляются все объекты данных, которые
должны учитываться при разработке приложения.
Архитектура интеграции
Архитектурой интеграции называется расширенная основа, позволяющая разным
приложениям, системам и сервисам взаимодействовать и эффективно работать
совместно. Она включает проектирование и реализацию методов и промежуточных инструментов, упрощающих обмен данными и процессы между разными
системами в организации или между организацией и внешними участниками.
Этот раздел в основном предназначен для поставщиков, партнеров и других
команд. Например, на рис. 16.9 показаны все точки интеграции с другими системами в приложении интернет-магазина.
614
Глава 16. Документирование архитектуры решений
Платеж
Поиск магазинов
Пользователь
Веб-сайт интернет-магазина
Отчет
Сервис аналитики
Платформа поставщика для обновления
каталога товаров
Каталог товаров
Сервер приложения
Система планирования ресурсов
предприятия (ERP)
Данные
продаж
Торговый представитель
Рис. 16.9. Диаграмма архитектуры интеграции для интернет-магазина
В разделе архитектуры интеграции перечислены все системы, которые предоставляют данные приложению. Здесь указываются любые платформы, сервисы
или базы данных, от которых приложение получает данные, а также природа
потоков данных и подробная информация о системах, которым приложение
отправляет данные. Это могут быть другие приложения, базы данных или
сервисы, зависящие от данных, производимых или обрабатываемых приложением. Необходимо перечислить все системные зависимости, относящиеся
к приложению.
Архитектура инфраструктуры
Этот раздел предназначен прежде всего для команды инфраструктуры
и системных инженеров. В него необходимо включить диаграмму развертывания с указанием логичного местоположения сервера и зависимостей.
Например, на рис. 16.10 представлена диаграмма развертывания приложения интернет-магазина. Можно добавить отдельные диаграммы для других
сред — например, сред разработки, контроля качества (QA) и приемочного
тестирования (UAT).
Структура SAD
615
Платформа интернет-магазина
Сервер
приложения
Браузер на десктопном
компьютере
HTTPS
Мобильное
приложение
Веб-сервер
JDBC
База данных
Рис. 16.10. Диаграмма развертывания интернет-магазина
В этом разделе перечисляются все конфигурации серверов, все базы данных,
сети и коммутаторы для развертывания приложения.
Архитектура безопасности
y
y
y
y
В этом разделе описываются параметры безопасности и комплаенса.
y Управление идентификационными данными и доступом (IAM, identity and
access management) — например, Active Directory (AD), механизм аутентификации пользователей и управление авторизацией.
y Инфраструктурные средства безопасности: конфигурация файрвола, система
предотвращения вторжений (IPS, intrusion prevention system) / система
обнаружения вторжений (IDS, intrusion detection system) и антивирусные
программы.
y Средства безопасности приложений — такие, как файрволы веб-приложений
(WAF) и защита от распределенных атак отказа в обслуживании (DDoS).
y Безопасность данных при хранении и передаче с использованием SSL, алгоритмов шифрования, управления ключами и т. д.
Архитектор решений также может включить модель угроз безопасности приложения для выявления потенциальных уязвимостей (таких, как межсайтовый
скриптинг (XSS) или SQL-инъекции (SQLi)) и планировать защиту приложения
от любых угроз безопасности.
616
Глава 16. Документирование архитектуры решений
Реализация решения
y
y
y
y
В разделе реализации решения приводятся основные соображения, которые
должны учитываться при разработке и развертывании решения. Он может содержать следующие основные подразделы.
y Разработка: этот подраздел важен прежде всего для команды разработки.
В нем обсуждаются инструменты разработки, язык программирования,
репозиторий кода, система контроля версий кода и ветвление, а также приводятся обоснования для выбора тех или иных вариантов.
y Развертывание: этот подраздел предназначен в основном для инженеров
DevOps, и в нем рассматриваются метод развертывания, инструменты развертывания, различные компоненты и чек-лист развертывания, а также
приводятся обоснования для выбора тех или иных вариантов.
y Миграция данных: этот подраздел поможет команде понять миграцию данных и механизм поглощения данных, область действия миграции, различные
объекты данных, используемые средства поглощения, источники и форматы
данных и т. д.
y Вывод приложения из эксплуатации: в этом подразделе перечисляются существующие системы, которые необходимо вывести из эксплуатации, а также
стратегия выхода для текущей системы, если показатель окупаемости не
достигнут. Архитектор решений должен предоставить метод и план-график
вывода старой системы из эксплуатации и оценить его общий эффект.
SAD включает общее описание подхода к разработке и инструментов. При этом
она не предполагает описания подробной структуры уровня приложения, такого
как диаграмма классов или псевдокод. Такие подробности должен указать архитектор продукта или сеньор-разработчик в соответствующем дизайн-документе
для продукта. После развертывания приложением необходимо будет управлять
в продакшен-среде. В следующем разделе рассматривается, какую информацию
необходимо включать в раздел управления решением.
Управление решением
Раздел управления решением предназначен для поддержки продукта и текущего обслуживания системы в других непродуктовых средах. В этом разделе
рассматриваются параметры эксплуатации решения, включая мониторинг,
управление инцидентами, онбординг пользователей, процессы поддержки
и восстановления.
Структура SAD
617
y
y
y
y
y
y
Раздел управления решением в основном предназначен для команды эксплуатации. Он раскрывает следующие темы.
y Операционное управление: установка патчей, обновление сред разработки,
тестирования, стейдж- и продакшен-среды.
y Инструменты для управления обновлениями приложения и выпуска новых
версий.
y Инструменты для управления инфраструктурой системы.
y Мониторинг системы и оповещения; операционный дашборд.
y Поддержка продакшен-среды, SLA и управление инцидентами.
y Аварийное восстановление и непрерывность бизнес-процессов (BPC,
business process continuation).
Архитектор решений должен анализировать и собирать данные для проверки
решения в процессе проектирования. Дополнительные подробности можно
включить в раздел SAD «Приложение», который мы рассмотрим далее.
Приложение
Как любой документ, описывающий бизнес-предложение, SAD предусматривает открытый раздел «Приложение», который содержит все данные, поддерживающие общую архитектуру и выбор тех или иных решений. В этот раздел
архитектор решений может включить открытые вопросы и любые данные
исследований: результат POC, данные сравнения инструментов, данные от поставщиков и партнеров и т. д.
Итак, мы представили полезный обзор структуры 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 x). В следующем разделе документ RFx рассматривается более подробно.
Документация на закупку IT-ресурсов
для архитектуры решения
Документация на закупку IT-ресурсов обычно называется RFx. Этот термин
объединяет разные стадии процесса закупки. Сокращение RFx относится к формальному процессу запроса на покупку. Документы RFx делятся на запросы
предложений (RFP, Request For Proposal), запросы информации (RFI, Request
For Information) и запросы цены (RFQ, Request For Quotation).
Архитекторы решений часто участвуют в процессе закупок, либо руководя им,
либо предоставляя информацию. Приобретение может относиться к услугам
аутсорсинга, заключению договоров, закупке программного обеспечения (например, баз данных или инструментов разработчика) или решений SaaS.
y
Поскольку такие документы могут содержать техническую информацию и с большой вероятностью будут иметь широкое, долгосрочное влияние, архитектор решения должен предоставить данные в соответствии с потребностями в приобретении.
Рассмотрим, чем же различаются перечисленные разновидности документов RFx.
y RFI: документы RFI относятся к ранней стадии закупочного процесса,
когда покупатели запрашивают информацию у разных поставщиков, чтобы
в дальнейшем принять обоснованное решение. Документ RFI содержит
информацию о возможностях разных поставщиков, чтобы покупатель мог
сравнить их по одинаковым параметрам и продолжить работу с поставщиками, прошедшими предварительный отбор. Например, компания изучает
рынок систем управления обучением (LMS, Learning Management System),
чтобы выбрать наиболее подходящую. Компания выпускает RFI для сбора
подробной информации о функциональности, возможностях интеграции
и пользовательских взаимодействиях доступных платформ LMS.
620
Глава 16. Документирование архитектуры решений
y
y RFP: в этом процессе поставщики, прошедшие предварительный отбор,
y
получают дополнительную информацию о результате проекта. Документ
RFP обычно более открытый, чем RFI, и поставщики могут предоставить
покупателю оптимальный вариант приобретения решений. Поставщик может
предложить несколько вариантов с описаниями достоинств и недостатков
каждого. Например, правительственное агентство хочет обновить свою
IT-инфраструктуру. Оно публикует RFP с описанием текущей системы,
требуемых улучшений и критериев эффективности. Поставщики отвечают
предложениями, содержащими технические решения, сроки реализации
проекта и оценку стоимости.
y 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) — необходимое и критически важное условие успешной карьеры архитектора решений.
Архитектор должен следить за трендами технологий, расширять свои знания
и всегда быть готовым узнавать новое. Чтобы стать хорошим архитектором
решений, необходимо непрерывное обучение. В этой главе рассматриваются
методы изучения новых технологий, а также возможности участвовать и вносить
вклад в техническое сообщество.
y
y
y
y
y
y
y
y
y
Архитектор должен определять и представлять общую техническую стратегию,
направленную на реализацию потребностей бизнеса. Ему необходимо работать
с техническими и бизнес-командами для нахождения лучшего решения, что
требует превосходных коммуникационных навыков. В этой главе вы узнаете,
какие гибкие навыки (включая коммуникационные) должен иметь архитектор
решений. Мы рассмотрим следующие темы.
y Важность гибких навыков.
y Приобретение навыков предварительных продаж.
y Принятие владения и ответственности за результат.
y Гибкость и адаптируемость.
y Дизайн-мышление.
y Непосредственное участие в написании кода.
y Развитие благодаря непрерывному обучению.
y Роль ментора.
y Роль технологического евангелиста и лидера мнений.
624
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
К концу этой главы вы будете знать о гибких навыках, необходимых успешному
архитектору решений. Вы узнаете, как приобрести стратегические навыки (такие,
как навыки предварительных продаж и коммуникации на высшем уровне), а также как развить дизайн-мышление и лидерские качества (масштабное мышление
и принятие владения). Вы узнаете, как занять позицию лидера и продолжить
совершенствовать свой набор навыков.
Важность гибких навыков
Важность гибких навыков для архитектора решения трудно переоценить, так как
они являются неотъемлемой составляющей его эффективности и успеха.
На первом месте — эффективные коммуникации. Архитектор решений должен
уметь упрощать сложные технические подробности для нетехнических стейкхолдеров, обеспечивая ясность и соответствие бизнес-целей техническим. Этот
навык чрезвычайно важен для налаживания связей между техническими и коммерческими подразделениями, что упрощает взаимопонимание и совместную
разработку целей.
Налаживание сотрудничества и командной работы — еще один важная задача
архитектора. Так как ему часто приходится работать в кроссдисциплинарных
командах, он должен уметь эффективно общаться с людьми, имеющими разную
степень подготовки и опыт. Сотрудничество важно для разрешения конфликтов, достижения консенсуса и формирования среды общей ответственности
и коллективного успеха.
Важнейшими навыками для архитектора решений являются также навык
решения задач и критическое мышление. Архитектор должен уметь ориентироваться в сложных технических проблемах и находить инновационные
решения, соотносящиеся с бизнес-стратегиями. Для этого потребуются понимание технологий, креативность, аналитическое мышление и ориентированность на поиск решений.
Наконец, лидерство и адаптируемость также играют важную роль. Архитекторы решений часто занимают лидерские позиции в проектных командах,
осуществляя техническое руководство и принимая поворотные решения. Это
требует навыков лидерства, а также умения вдохновлять, мотивировать и направлять деятельность команд к общим целям. Кроме того, технологическая
сфера непрерывно меняется, поэтому адаптируемость и ориентированность на
обучение позволяют архитекторам идти в ногу со временем и реагировать на
новые тенденции и технологические сдвиги. Эти гибкие навыки в сочетании
с техническим опытом делают архитектора решений бесценным сотрудником
в любой организации.
В следующих разделах рассматриваются некоторые ключевые гибкие навыки,
которыми должен обладать архитектор решений в рамках более общих навыков,
перечисленных в этом разделе.
Приобретение навыков предварительных продаж
625
Приобретение навыков предварительных
продаж
Предпродажный этап — чрезвычайно важная часть приобретения сложных
технологий, когда заказчик собирает подробную информацию для принятия
решения о покупке. В организации клиента архитектор решений участвует
в предпродажном цикле для проверки технологических и инфраструктурных
ресурсов от различных поставщиков. В организации поставщика он отвечает на
запросы предложений (RFP) и представляет потенциальное решение, позволяю
щее получить нового клиента. Для этого ему требуется особый набор навыков.
Ключевые навыки
y
y
y
Предпродажа требует особого набора навыков, включающего сильные технические знания и гибкие навыки.
y Коммуникации и ведение переговоров: архитектору решений необходимы
отличные навыки коммуникации для общения с клиентами и передачи
актуальной информации. Точные детали решения и его актуальность для
отрасли помогут клиенту понять, как оно может решить его бизнес-проблему. Архитектор решения служит связующим звеном между отделом продаж
и техническими командами, поэтому коммуникация и координация очень
важны. Архитекторы решений также должны обеспечивать соглашения,
сотрудничая с клиентами и внутренними командами, для чего необходимы
отличные навыки ведения переговоров. В частности, решения стратегического
уровня оказывают значительное влияние на несколько групп. Архитекторы
решений должны вести переговоры между командами, прорабатывать компромиссы и создавать оптимизированные решения.
y Слушание и решение задач: архитектору необходимы сильные аналитические
навыки, чтобы определить решение, соответствующее потребностям клиента.
Архитектор решений должен слушать и понимать юзкейсы клиента, а также
задавать правильные вопросы. Он должен уметь видеть пробелы и разрабатывать решения, помогающие достичь бизнес-результатов немедленно и окупаемые в долгосрочной перспективе. Для одних клиентов может быть более
важна производительность, тогда как для других — затраты, в зависимости
от пользовательской базы приложения. Архитектор должен предоставить
подходящее решение в соответствии с основными KPI клиента.
y Клиентоориентированность: архитектору часто приходится работать как
с внутренними, так и с внешними заказчиками. Архитектор влияет на
стейкхолдеров на всех уровнях, от руководителей высшего звена до инженеров-разработчиков. Он представляет решения и демоверсии старшему
руководству, которое рассматривает предложение с точки зрения бизнеса.
Поддержка руководителей высшего звена и их приверженность инициативам всегда служат залогом успеха выбранного решения, поэтому навыки
626
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
y
клиентоориентированности играют очень важную роль. Руководители высшего звена изучают подробности решения на специально организуемой
встрече, и архитектор должен использовать выделенное время максимально
эффективно. Коммуникация с высшим руководством более подробно рассматривается в следующем разделе этой главы.
y Работа с командами: архитектор формирует отношения с командами
бизнеса и продукта. Чтобы разработать оптимальное приложение, архи
тектор решений должен взаимодействовать с техническими и бизнес-
командами на всех уровнях. Архитектор решений должен уметь работать
в команде, обмениваться идеями и искать возможности для сотрудничества
команд.
Указанные навыки необходимы для предпродаж; кроме того, они применимы
и в повседневной работе архитектора. Архитекторами становятся технические
специалисты, и на такой позиции им необходимо развивать навыки коммуникации на всех уровнях. Коммуникация с высшим руководством рассматривается
в следующем разделе.
Представление решения руководителям высшего звена
Архитектор решения должен уметь решать различные технические и бизнесвопросы. Одной из самых сложных задач может стать получение одобрения со
стороны руководства.
Руководители высшего звена — это генеральный директор (CEO), технический
директор (CTO), финансовый директор (CFO), руководители направлений,
IT-директор (CIO). Такие руководители имеют напряженный рабочий график
и принимают много ответственных решений.
Архитектор решений должен представить множество подробностей, но встречи
с руководителями высшего звена ограничены по времени. Поэтому необходимо
извлечь за выделенное время максимум практической пользы. Главный вопрос:
как добиться внимания и поддержки старшего руководства за ограниченное время?
Начните с объяснения повестки и запланированной структуры встречи. Руководители задают много вопросов, и вы должны предусмотреть время для
уточняющих вопросов и ответов. В презентации решения руководителям самое
важное — дать краткое резюме основных тезисов за первые 5 минут. Вы должны
быть готовы к тому, чтобы передать суть проекта и получить одобрение для
следующего шага, даже если запланированная получасовая встреча сократится
до этих пяти минут.
Предоставьте сводку фактов и данных, имеющих отношение к отрасли и организации. Держите подробности наготове на случай, если руководители захотят
глубже изучить конкретный вопрос; будьте готовы быстро получить и представить все необходимые данные.
Приобретение навыков предварительных продаж
627
Не пытайтесь изложить все подробности, в том числе информацию, которая
может казаться важной вам, но не имеет особого смысла для руководства.
Например, вам как архитектору решений могут быть важны преимущества
технической реализации. При этом руководство будет больше интересовать
величина окупаемости за счет сокращения расходов на эксплуатацию и повышения эффективности.
Используйте в своей демонстрации или презентации отраслевую и клиентскую
терминологию. Термины и концепции, знакомые слушателям, не только формируют доверие, но и свидетельствуют, что вы адаптировали свое техническое
решение для эффективного решения специфических проблем.
y
y
y
y
y
y
При общении с руководителями приготовьтесь ответить на следующие вопросы.
y Какую пользу предлагаемое решение принесет нашим клиентам? В бизнесе центральное место занимает клиент. Целью руководителей является
рост компании, а он возможен только в том случае, если клиенты довольны.
Обязательно проведите исследования клиентской базы и ее потребностей. Будьте готовы описать преимущества, подкрепленные надежными
данными.
y На каких предположениях основан выбор базовых параметров решения?
Часто встречи с руководством проводятся на начальном этапе, когда нужна
более подробная информация. Архитекторы решений всегда должны сделать
несколько допущений, которые станут основой решения. Составьте список
гипотез и подготовьте запасной план на случай, если предположения окажутся неверными.
y Какая окупаемость предполагается? При определении суммарной стоимости владения (total cost of ownership, TCO) руководители всегда учитывают окупаемость (ROI). Рассчитайте оценочную стоимость владения,
затраты на обслуживание решения, расходы на обучение, размер общей
экономии и т. д.
y Что будет, если мы оставим все как есть и ничего не сделаем? Для выяснения окупаемости высшее руководство может устраивать очень тщательный
разбор предлагаемых решений. Руководителям необходимо понимать, оправдаются ли вложения. Желательно иметь наготове результаты исследований
рынка — например, технологических и клиентских тенденций и анализа
конкурентов.
y Как наши конкуренты отреагируют на решение? Конкуренция повсюду,
и руководители думают о ней. Они хотят понять, будет ли ваше решение
достаточно инновационным, чтобы превзойти конкурентов и предоставить
организации преимущество. Лучше заранее провести соответствующие
исследования и добавить данные о конкурентах, касающиеся их отрасли
и клиентской базы.
y Что вы предлагаете и как я могу помочь? Во время презентации предложений у вас всегда должен быть наготове краткий список конкретных действий,
628
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
запланированных на следующий этап. Вам нужно заручиться одобрением
руководства и вовлечь его в проект, обратившись за содействием. Например,
можно попросить у IT-директора связать вас с инженерной командой или
командой продукта, чтобы перевести решение на следующий этап.
В следующем разделе рассматриваются лидерские навыки, которыми должен
обладать архитектор решений как техлид организации.
Принятие владения и ответственности
за результат
Принятие владения решением и позиционирование себя в качестве лидера
помогут завоевать доверие благодаря принятию ответственности за результат.
Владение не означает, что вы будете делать все самостоятельно: это подразумевает выбор новых инициатив и внедрение их в организации. У вас могут быть
идеи, способные принести практическую пользу организации в отношении
производительности, адаптивности, экономии и расширения клиентской базы.
Иногда реализация идеи требует большого количества времени или ресурсов,
но стоит предложить ее как новую инициативу и привлечь к ее реализации
других сотрудников.
При этом вы принимаете на себя ответственность за полученный результат.
Владение и ответственность за результат связаны: вы создаете инициативу
и работаете над ее реализацией. Вам доверяют выполнение работы и достижение результата. Ответственность способствует формированию доверительных
отношений с клиентами и командой, что формирует благоприятную рабочую
среду и помогает достичь поставленной цели.
Для архитектора решений принятие владения помогает увидеть ситуацию с точки зрения клиентов и спонсоров. Вы чувствуете себя частью чего-то значимого,
что вам нравится. Постарайтесь определить цели и ключевые результаты. Цель/
результат должны быть измеримы по конкретным ключевым показателям и ограничены по времени. Система целей и ключевых результатов (OKR, Objectives
and Key Results) более подробно рассматривается в следующем разделе.
Определение исполнения стратегии с учетом OKR
Исполнение стратегии — комплексная и сложная задача. Успешное исполнение
стратегии необходимо для понимания вˆидения, миссии и целей организации.
Идея должна трансформироваться в действия, которые можно выполнить,
чтобы команды работали согласованно и все двигались в одном направлении.
Постановка целей и управление ими — один из самых проверенных способов
достижения результатов.
Метод OKR представляет принципы и практики (вˆидение и исполнение) постановки целей. OKR — система управления стратегией, уделяющая основное
Принятие владения и ответственности за результат
629
y
y
y
y
внимание исполнению; простая основа, которая позволяет определить первоочередные стратегии и приоритеты организации. Цели — это принципы,
а ключевые результаты — практики, соответственно отвечающие на вопросы
«что?» и «как?». В основе OKR лежат четыре движущие силы, показанные
на рис. 17.1.
y Фокус: начните с вопроса: каковы наши основные приоритеты и на чем
необходимо сосредоточить усилия? Стремитесь к тому, что на самом деле
важно, и доступно объясните, чего вы добиваетесь.
y Согласованность: сделайте цели открытыми и прозрачными. Связывайтесь
с командой и обеспечивайте горизонтальную и вертикальную согласованность, а также согласованность внутри команды.
y Отслеживание: обеспечьте наглядное отслеживание ключевых результатов
по каждой цели в процентах.
y Амбициозные цели: ставьте цели по достижению действительно заметных
результатов. Амбициозные цели помогают переосмысливать ситуацию.
Методика OKR задает ясные, измеримые цели и согласует их со стратегической
миссией организации. В архитектуре решений OKR может направлять ход проектирования и реализации систем, чтобы обеспечить их вклад в глобальные
цели бизнеса.
Согласованность
Движущие силы
OKR
Фокус
Отслеживание
Амбициозные цели
Рис. 17.1. Движущие силы OKR
630
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Для архитектора решений OKR могут выглядеть примерно так.
Цель: повышение стабильности и отказоустойчивости системы.
y
y
y
Ключевые результаты:
y снижение времени неработоспособности системы на 30 % за следующий
квартал;
y реализация мультизонной стратегии развертывания для критически важных
сервисов к следующему циклу выпуска;
y достижение 99,99 % доступности для пользовательского уровня приложения
в течение 6 месяцев.
В этом примере архитектор использует OKR для постановки четких целей по
производительности и надежности системы, которые входят в число его важнейших зон ответственности. OKR также помогают назначать приоритеты задачам,
оценивать прогресс и доводить информацию о последствиях архитектурных
решений до стейкхолдеров.
Метод OKR обеспечивает видимость и представление значимых результатов
всем стейкхолдерам на разных уровнях, от руководящих спонсоров проекта
до рабочих команд. OKR проясняют вˆидение и миссию организации. Вˆидение
и ясная формулировка миссии необходимы членам команд в их повседневной
работе; они должны понимать, как их действия влияют на цели. OKR позволяет
определить эту связь и представить общее вˆидение и значимость происходящего
всем участникам команд.
Масштабное мышление
Архитектор решений должен быть способен видеть общую картину и прогнозировать будущее. Он создает основу, на которой команда размещает стандартные
блоки и запускает продукт. Масштабность мышления — один из важнейших
навыков, которыми должен обладать архитектор решений для обеспечения
долговечности приложения.
Масштабное мышление не означает, что вы должны ставить нереалистичные
цели. Но цель должна быть достаточно амбициозной, чтобы потребовать от вас
значительных усилий и вывести из зоны комфорта.
По сути, масштабное мышление направлено на прогнозирование потребностей
организации и опережение технологических достижений, чтобы текущий дизайн можно было адаптировать для будущих потребностей, поддерживая его
эффективность. Масштабное мышление необходимо для достижения успеха
как на персональном уровне, так и на уровне организации.
Мысля масштабно, оставайтесь уверенными в своих способностях. Сначала задача
может казаться сложной, но вы непременно найдете нужный путь, когда начнете
двигаться к цели. Поверьте в себя, и вы заметите, что другие начинают вас поддерживать и верить в вас. Масштабное мышление помогает вдохновлять окружающих,
Гибкость и адаптируемость
631
чтобы они стали частью вашего успеха. Ставьте долгосрочные цели — например,
отвечая на вопрос, как вы видите себя и свою организацию в следующем десятилетии.
Шаг за шагом трансформируйте краткосрочные цели в долгосрочные.
Постановка амбициозных целей за счет масштабного мышления поможет вам
взять инициативу на себя и исследовать новые возможности. Тем не менее для
достижения результата желательно заручиться поддержкой со стороны коллег
и команды, которые могут предоставить необходимую обратную связь и оказать
содействие. Станьте тем, кому захотят помогать другие; впрочем, это работает
в обоих направлениях. Чтобы получить помощь, вы должны быть открыты для
помощи другим. Адаптируемость — еще один важнейший навык архитекторов
решений, необходимый, чтобы работать с другими людьми. В следующем разделе он рассматривается более подробно.
Гибкость и адаптируемость
Адаптируемость и гибкость тесно взаимосвязаны, и архитектор решений должен
проявлять достаточную гибкость, чтобы адаптироваться к новым средам, рабочим
культурам и технологиям. Адаптируемость означает, что вы всегда открыты для
новых идей и работы с соответствующими им командами.
Команды могут использовать процессы и технологии, которые лучше всего
им подходят. Архитектор решений должен быть достаточно гибким, чтобы
учитывать требования команд на этапе проектирования решения. Например,
в микросервисной архитектуре каждый сервис взаимодействует через стандартный API RESTful по протоколу HTTP. Команды могут писать код на разных
языках: Python, Java, Node.js или C#. Единственное требование заключается
в том, чтобы все команды предоставляли безопасный доступ к API и вся система
могла строиться на его использовании.
Вам потребуется менять образ мышления и точку зрения на проблемы, а также
уметь находить инновационные решения. Если команды будут придерживаться
принципа быстрого провала (fail fast) и внедрять инновации, это поможет организации оставаться конкурентоспособной.
y
y
y
y
Перечислим некоторые проявления гибкости.
y Умение видеть разные возможные решения задач в команде и выбирать
лучший способ.
y Помощь участникам команды с делегированием работы.
y Добровольное согласие занять место в команде, если какому-то участнику
требуется покинуть ее на несколько недель по личным обстоятельствам.
y Умение эффективно сотрудничать с командами в разных регионах и часовых
поясах.
Необходимо сохранять открытость и уметь адаптироваться к изменениям технологий и процессов. При внедрении изменений в команде или организации
можно столкнуться с сопротивлением. Необходимо убеждать других проявлять
632
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
гибкость и разъяснять важность изменений. Например, если организация хочет
переместить свою рабочую нагрузку из локальной среды в облако, ей обычно
требуется больше поддержки, так как разработчикам приходится изучать новую
платформу. Необходимо рассказать о пользе перехода в облако и о том, как это
поможет сотрудникам действовать более адаптивно и ускорить инновации.
Архитектор решений должен уметь работать в режиме многозадачности и назначать приоритеты выполнения. Он должен уметь подстраиваться под ситуацию
и работать в условиях стресса.
Архитектор решений должен обладать критическим дизайн-мышлением, чтобы
создавать инновационные решения. Эта тема более подробно рассматривается
в следующем разделе.
Дизайн-мышление
Архитектор решений играет ведущую роль в проектировании систем, поэтому
навык дизайн-мышления ему критически необходим. Дизайн-мышление — один
из самых успешных подходов, внедряемых в разных отраслях для решения сложных и неочевидных задач. Оно помогает рассматривать задачи и решения с новой
точки зрения, которую заранее нужно тщательно продумать. Дизайн-мышление
в основном направлено на получение результатов за счет применения подхода,
ориентированного на решение. Оно дает возможность критически оценивать
задачу, решение и сопутствующие риски для разработки оптимальной стратегии.
Дизайн-мышление помогает переопределять задачи с учетом клиентоориентированности, для чего следует поставить себя на место конечных пользователей
и клиентов. На рис. 17.2 показаны основные принципы дизайн-мышления.
y
y
y
y
y
y
Назовем некоторые принципы дизайн-мышления.
y Частые эксперименты: создайте прототип, чтобы понять реализацию идеи
в реальных сценариях. Внедрите стратегию быстрого провала (fail fast) и экспериментируйте чаще.
y Разноплановое сотрудничество: привлекайте людей с разным опытом работы, чтобы представлять проблемы с разных точек зрения, и следите, чтобы
решения учитывали все потребности.
y Фокус на клиента: собирайте обратную связь от разных пользователей.
Ставьте себя на их место, чтобы взглянуть на задачу под другим углом.
y Наглядная демонстрация: выразите свои мысли в наглядной форме, чтобы
вашим собеседникам было проще понять их.
y Четкое определение задачи: создайте четко определенное и понятное вˆидение
задачи, которое поможет другим понять ее и стимулирует к участию в ее
решении.
y Продуманный процесс проектирования: четко представьте себе общий процесс проектирования с ясными целями и методами.
Дизайн-мышление
Наглядная демонстрация
Фокус
на клиента
633
Четкое определение задачи
Принципы
дизайнмышления
Продуманный процесс
проектирования
Частые
эксперименты
Разноплановое
сотрудничество
Ориентация
на действия
Рис. 17.2. Принципы дизайн-мышления
y
y Ориентация на действия: конечная задача проектирования — поставить го-
товое, а не мысленное решение. Будьте проактивны и совершайте действия,
которые приведут вас к работоспособному решению.
Дизайн-мышление лежит в основе эмпатии и создания целостного представления
задачи. Для выработки дизайн-мышления существует модель из пяти этапов,
предложенная d.school (https://dschool.stanford.edu/resources/getting-started-withdesign-thinking) — пионерами в обучении дизайн-мышлению и его применении.
Эти этапы показаны на рис. 17.3.
y
Дизайн-мышление — итеративный подход, который должен непрерывно развиваться. Выходные данные одного этапа могут рекурсивно передаваться на
вход других этапов, пока решение не примет конечную форму. Вот краткое
описание этапов.
y Эмпатия, то есть способность к сопереживанию, — структурный элемент
и основа проектирования в человеческом контексте. Чтобы сопереживать, необходимо наблюдать за поведением пользователей и общаться
с ними; это позволит понять суть проблемы. Попробуйте углубиться
в проблему и почувствовать ее на себе, представив себя в соответствующей
ситуации.
634
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Эмпатия
Этапы дизайн-мышления
Определение
Оформление идеи
Разработка прототипа
Тестирование
Рис. 17.3. Пять этапов дизайн-мышления
y
y Определение: эмпатия помогает определить задачу, когда вы переживаете
y
y
y
потребности пользователя и проблемы, с которыми он сталкивается. На этапе
определения вы применяете полученные выводы и четко формулируете задачу, что может инициировать мозговой штурм для поиска инновационного,
но простого решения.
y Оформление идеи: суть этого этапа заключается в переходе от задачи
к решению. Вы работаете с командой и ищете альтернативные решения,
пересматривая предположения. Не зацикливайтесь на очевидном решении
и работайте совместно в поисках всех возможных решений, что открывает
возможность инноваций.
Разработка
прототипа: прототипирование помогает преобразовать идеи
y
в конкретные решения. Прототипы могут стать отличным обучающим
материалом и помогут устранить разногласия за счет демонстрации подтверждения концепции (POC). Это поможет выявить пробелы и риски.
Прототип должен создаваться быстро и без значительных вложений, помогая
преодолевать сбои и повышать качество обучения.
y Тестирование: этот этап подразумевает получение обратной связи по решению
и его соответствующий пересмотр. Тестирование помогает переопределить
решение и больше узнать о пользователях.
Дизайн-мышление объединяет все перечисленные этапы в разработку логичного
и практического решения. При проектировании архитектуры решения можно
связать этапы и принципы дизайн-мышления с реальными ситуациями. Особенно важно создать прототип, так как это единственный способ подтвердить
ваше предложение и существующие решения данными и фактами. Главная задача архитектора решений — понять интересы бизнеса и разработать прототип
Развитие благодаря непрерывному обучению
635
технического решения, которое может реализовать команда. Чтобы создать прототип, архитектору решений придется засучить рукава и заняться написанием
кода. В следующем разделе эта тема рассматривается подробнее.
Участие в написании кода
Архитектор решений — строитель, который учится на практике. Прототип стоит
тысячи схем. Он помогает устранить любые недоразумения и оформить идею
решения. Представление POC и прототипирование — неотъемлемые составляющие работы архитектора решений.
Прототипирование — этап, предшествующий построению решения, углубляющий понимание дизайна приложения и особенностей пользователя. Прототип
помогает в осмыслении и построении разных путей решения. Тестируя прототип,
можно улучшить решение и вдохновить других (например, команды, клиентов
и инвесторов) демонстрацией своего вˆидения.
Архитектор решений — это технический лидер, который тесно взаимодействует
с командой разработки. В динамичной команде талантливых разработчиков
архитектор решений должен представить в качестве POC фрагмент кода в дополнение к презентации PowerPoint. Архитектор решений не обязан быть частью
команды разработки, но он должен продемонстрировать решение на понятном
ей языке. Поставка будет успешной только в том случае, если архитектор решений сможет вникнуть в технические параметры решения, которые становятся
понятны только при написании кода и на практическом опыте.
К архитектору решений часто относятся как к ментору или играющему тренеру;
практический кодинг помогает наладить доверительные отношения. Архитектор
решений подбирает языки программирования и инструменты для команды.
Практический подход помогает выявить элементы, которые могут не соответствовать требованиям команды или продукта, — постоянное изучение новых
технологий поможет вам принимать лучшие решения в интересах организации.
Рассмотрим непрерывное обучение более подробно.
Развитие благодаря непрерывному обучению
Архитектор решений должен непрерывно получать новые знания и расширять
свой кругозор, чтобы помогать организации принимать более эффективные
решения. Непрерывное обучение поддерживает актуальность набора навыков
архитектора и формирует доверие в команде. Оно помогает мыслить объективно
и при необходимости менять точку зрения.
Полная занятость и личная жизнь оставляют мало времени для обучения. Суть
непрерывного обучения — формирование привычки всегда узнавать что-то
новое, для чего потребуется мотивация и дисциплина. Прежде всего необходимо поставить цели обучения и для их достижения использовать эффективные
методы тайм-менеджмента.
636
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Разным людям нужны разные стили обучения. Одним лучше подходит формальное образование; другие выбирают чтение книг; третьи предпочитают слушать
и смотреть обучающие ролики. Найдите то, что наиболее эффективно лично
для вас и лучше всего подходит к вашему стилю жизни.
y
y
Например, можно слушать аудиокниги и учебники по дороге на работу. Можно
читать книги во время деловых перелетов или смотреть обучающее видео во
время занятий в фитнес-центре. В целом вам придется постараться, чтобы выделить время из занятой жизни на непрерывное обучение. Ниже рассматриваются
некоторые способы мотивировать себя к непрерывному обучению.
y Изучайте новые технологии, фреймворки и языки, применяя их на практике:
архитекторы решений должны быть готовы к практическим экспериментам.
Успешный архитектор решений должен осваивать новые технологии на небольших проектах. Понимание современных языков программирования и фреймворков поможет рекомендовать организации и команде лучшие технологии.
y Осваивайте новые навыки, читая книги и учебники: у традиционного чтения
бумажных книг много преимуществ, особенно в контексте целенаправленного обучения. Книги изолируют от отвлекающих факторов интернета, что
позволяет сконцентрировать внимание.
Такой подход особенно полезен для тех, кто проводит бˆольшую часть дня за
экраном монитора, так как он обеспечивает отдых для глаз. Чтение бумажных
книг может повысить эффективность обучения за счет сокращения «цифровой усталости» и полного погружения в материал.
В Kindle доступны миллионы электронных книг, которые можно читать
когда и где угодно. Такие платформы аудиокниг, как Audible и Google Play,
предоставляют возможность слушать книги во время поездок. Нам доступно
так много удобных ресурсов, что отказу от непрерывного обучения просто
нет оправдания.
y
Обучение в интернете стало революцией. Оно позволяет легко понять и глубоко изучить любую область. У вас под рукой находятся огромные объемы
данных, по которым можно изучать что угодно. Такие интернет-платформы,
как Udemy или Coursera, предоставляют тысячи учебных видеороликов по
всем темам; их можно смотреть в интернете или загружать на устройство для
автономного просмотра.
y Будьте в курсе технологических новостей, читая статьи на сайтах и в блогах: лучший способ не отставать от технологических достижений — подписка на технические новости и блоги. TechCrunch.com, Wired.com и Cnet.
com — популярные сайты, на которых вы найдете актуальную информацию
о технологических новинках. Крупные газеты CNBC, The New York Times,
каналы BBC News и CNN также публикуют статьи с полезной информацией
об отраслевых тенденциях. Чтобы быть в курсе полезной информации в соответствующих технологических областях, можно подписаться на блоги.
Развитие благодаря непрерывному обучению
637
y
y
y
y
y
Например, в изучении облачных платформ помогут блоги AWS (Amazon
Web Services) с тысячами статей и примеров использования облака AWS;
аналогичные блоги существуют и для других публичных облачных платформ,
включая Azure и GCP (Google Cloud Platform).
y Пишите посты в блогах, статьи или книги: делиться знаниями — лучший
способ чему-то научиться, так как, рассказывая о своем опыте другим, вы
тщательно продумываете возможные сценарии использования. Публикация
блогов и статей на популярных платформах — Medium, Blogger, LinkedIn —
помогает распространять знания и учиться у других. Активно участвуя
в работе платформ вопросов/ответов, вы сможете находить альтернативные
решения для любых задач. Некоторые популярные платформы вопросов/
ответов — Quora, Reddit, Stack Overlow и Stack Exchange.
y Укрепляйте свои знания, обучая других: в процессе обучения вы общаетесь
с другими людьми и получаете возможность взглянуть на свои знания под новым
углом. Сценарии использования, предлагаемые участниками, часто содержат
новые пути решения. Проводя семинары с практической частью и формированием концепций, вы сможете укрепить свои знания и научить других.
y Учитесь в интернете: иногда формальное обучение требует слишком жесткой дисциплины, а вам нужно больше гибкости. Учебные курсы в интернете
обеспечивают гибкость, помогают скорректировать приоритеты и сэкономить
время. Они предоставляют организованные средства изучения новых технологий и расширения знаний.
y Учитесь у коллег: коллеги работают в одной среде с вами, и вы проводите
большую часть своего рабочего времени с ними. Общение с коллегами может
ускорить обучение. Команда может применять стратегию, когда участники
рассказывают о своих темах и проводят учебные семинары за обедом. Каждый
участник еженедельно делится новыми знаниями, и все остальные быстро
их осваивают.
y Посещайте и участвуйте в работе пользовательских групп и конференций:
все крупные промышленные и технологические организации проводят конференции и практические семинары для распространения информации о новых
технологических тенденциях. Участие в отраслевых конференциях и встречах
способствует развитию нетворкинга и пониманию технологических тенденций. Среди крупных конференций от отраслевых лидеров можно упомянуть
AWS re:Invent, Google Cloud Next, Microsoft Ignite, SAP SAPPHIRE и Strata
Data Conference. Также можно создать локальную группу пользователей
и организовать встречу в вашем регионе, чтобы наладить сотрудничество
с профессионалами из других отраслей и организаций.
Непрерывное профессиональное развитие исключительно важно для архитектора решений. Стремительное развитие технологии обязывает к периодическому
обновлению сертификатов и удостоверений, чтобы не отставать от новых достижений и отраслевых стандартов.
638
Глава 17. Гибкие навыки, которые нужны хорошему архитектору решений
Архитектор решений играет роль технологического лидера, а хороший лидер
должен готовить других лидеров. Для этого существует система наставничества
(менторства). В следующем разделе роль ментора рассматривается более подробно.
Роль ментора
В качестве ментора вы помогаете другим и готовите их к успеху, руководствуясь
своим опытом. Это эффективный способ подготовки лидеров на основе индивидуального взаимодействия ментора с ментˆи (учеником).
Чтобы быть хорошим наставником, необходимо выработать неформальный стиль
общения, при котором ученик будет чувствовать себя комфортно. Ученик может
задавать вопросы из разных областей — например, касающиеся карьерного развития или личных вопросов (таких, как баланс работы и личной жизни). Проведите
неформальную оценку потребностей и определите взаимные цели и ожидания.
Ментор должен больше слушать, чем говорить. Иногда людям нужно, чтобы их
кто-то выслушал и дал полезный совет. Всегда внимательно слушайте ученика
и поймите его точку зрения.
Помогите ученику принимать самостоятельные решения, чтобы он ощущал, что
делает что-то своими силами. Давая советы по карьерному росту, хороший ментор
должен следить, чтобы они соответствовали интересам ученика, даже если они
неидеальны для компании. Всегда предоставляйте честную, конструктивную
обратную связь, чтобы помочь ученикам выявлять и преодолевать препятствия.
Важнейшее качество ментора — умение вдохновлять других. Часто люди выбирают кого-то наставником, если они видят в нем образец для подражания.
Помогите своим ученикам раскрыть их потенциал и добиться того, о чем они
даже не догадывались. Роль ментора всегда приносит обоюдную пользу; вы
также узнаете от своих учеников что-то новое о поведении людей и их профессиональном росте. Наставничество в конечном счете поможет вам стать лучше
и как руководителю, и как человеку.
Чтобы перевести свой опыт на новый уровень, вы можете стать технологическим
евангелистом и лидером мнений. Эта тема рассматривается в следующем разделе.
Роль технологического евангелиста
и лидера мнений
Технологический евангелист — это эксперт, продвигающий использование
определенной технологии и продукта. В некоторых организациях с широкой
базой продуктов существует отдельная должность технологического евангелиста. Однако часто эту роль берет на себя архитектор решения. Евангелист
должен разбираться в текущих технологических тенденциях, чтобы понимать
реальные проблемы и выступать за применение продвигаемой технологии для
удовлетворения интересов бизнеса.
Итоги
639
Технологический евангелист участвует в отраслевых конференциях в качестве
докладчика и продвигает свою платформу. Это позволяет ему стать авторитетным
экспертом и лидером мнений, что может способствовать росту популярности
платформы и продукта. Навык публичных выступлений — один из важнейших
навыков архитектора решений, потому что ему приходится общаться на разных
открытых платформах и в больших аудиториях.
Евангелист также пишет и публикует статьи и посты в блогах и ведет микроблоги для продвижения своего продукта. Он распространяет информацию для
повышения лояльности к продукту и общается с пользователями, чтобы получать обратную связь. Затем он передает ее внутренней команде, чтобы улучшить
продукт. Со временем вы, как евангелист, сможете более четко формулировать
месседж, наиболее эффективно продвигающий интересы организации.
Роль архитектора решений подразумевает набор разнообразных обязанностей,
и дополнительная ответственность будет способствовать успеху вашей карьеры.
Итоги
В этой главе рассматривались гибкие навыки, необходимые для успешной
работы архитектора решений, и их важность. Архитектору решений требуются
навыки предварительных продаж, которые помогут ему обеспечить поддержку
предпродажного цикла организации — например, с помощью RFP.
Вы узнали о навыках представления информации, необходимых для общения
с руководством и получения одобрения, и стратегическом мышлении, которым
должен обладать архитектор решений, чтобы определять для организации ключевые цели и результаты. Чтобы работать на разных уровнях, архитектор решений
должен мыслить масштабно, быть гибким и уметь адаптироваться. В этой главе
было рассказано о том, как архитекторы решений принимают на себя владение
своими действиями и ответственность за результат
Основная обязанность архитектора решений — проектирование архитектуры.
Вы узнали о дизайн-мышлении, его принципах и составляющих. Также мы рассмотрели важность непрерывного обучения и приемы, позволяющие оставаться
в курсе новейших тенденций рынка. Мы изучили дополнительные обязанности
архитектора решений — роли ментора и евангелиста.
Мы прошли большой путь. Вы узнали об архитекторах решений все: от их ролей
и обязанностей до параметров проектирования решений и оптимизации архитектур. Надеюсь, полученные знания помогут вам построить карьеру архитектора
решений или добиться успеха в текущей должности.
Счастливого обучения!
Комьюнити рецензентов
и переводчиков ИТ-литературы
Миссия участников клуба — обеспечить
высокое качество профессиональной
переводной литературы в России.
«Книжные дебагеры» проверяют
корректность терминологии и подписей
на схемах и иллюстрациях, чтобы сделать
книги более понятными русскоязычному
читателю. Стать участником Read IT Club
может любой ИТ-специалист, готовый
поделиться опытом с сообществом.
присоединиться к нам