Облака на практике: выбор, миграция, экономика

Проект ЦИТадель

Теоретическая статья пары разобрала, что такое облако и из чего оно сделано; эта — о решениях, которые принимают люди: как выбирать провайдера и уровень сервисов, что такое привязка к вендору и сколько она стоит, как устроена управляемая миграция и куда уходят облачные деньги. Формат — как в статье о надёжности: правила с обоснованиями и типичными ошибками, а не обзор тарифов, которые устареют к публикации. Сквозная мысль: в облаке нет решений «правильных вообще» — есть решения, соответствующие или не соответствующие вашей нагрузке, команде и экономике; статья учит проводить эту сверку.

1. Выбор: анкета вместо сравнения логотипов

Вопрос «какой провайдер лучше» поставлен неверно — выбирают не провайдера, а набор сервисов плюс модель эксплуатации. Анкета в духе нашего семинара по проектированию (глава 12 курса), по убыванию жёсткости ограничений:

1. Данные и регуляторика: где юридически могут находиться ваши данные, какие требования предъявляются к оператору и какие подтверждения соответствия нужны? Сертификат провайдера сам по себе не делает соответствующей требованиям вашу систему: важны выбранный сервис, регион, конфигурация и договор. Этот пункт проверяют с профильными специалистами до сравнения цен.
2. Критичные managed-сервисы: какие 3–5 сервисов понесут ядро системы (СУБД нужной вам породы, брокер, Kubernetes, объектное хранилище)? Сравнивайте провайдеров по зрелости именно их, а не по длине каталога: каталог у всех необъятен, а живёте вы с пятью строчками.
3. Профиль нагрузки: кривая из раздела 5 теоретической статьи — эластичная или ровная? От неё зависит и сама целесообразность, и модель оплаты (по потреблению / резервы / гибрид с собственным железом).
4. Команда: недостаток эксплуатационной экспертизы может быть доводом в пользу PaaS вместо IaaS, но managed-сервис всё равно требует понимания данных, доступов, резервирования, ограничений и аварийных процедур. Чем выше уровень сервиса, тем важнее качество и прозрачность managed-слоя.
5. Стоимость выхода: перенос данных и тарифы egress, замена непереносимых сервисов, период двойной эксплуатации, проверка данных и изменение процессов. Посчитайте её до подписания договора и пересматривайте по мере изменения архитектуры.

2. Привязка: кредит, а не грех

Разговоры о vendor lock-in обычно ведутся в жанре морали; полезнее — в жанре бухгалтерии. Привязка — это кредит: проприетарный сервис даёт скорость сегодня в обмен на стоимость выхода завтра. Как всякий кредит, её надо брать осознанно и знать слои по нарастанию процента:

• слабая — виртуальные машины, диски, сети: форматы знакомы, но перенос всё равно затрагивает образы, адресацию, IAM, данные и средства автоматизации;
• средняя — managed-версии открытых систем (PostgreSQL, Kafka, Kubernetes): базовые форматы и API известны, но расширения, версии, режимы резервирования и эксплуатационная обвязка могут различаться;
• сильная — проприетарные сервисы без внешнего аналога (фирменные serverless-платформы, событийные шины, ML-конвейеры): переезд = переписывание.

Валюта переносимости — открытые интерфейсы, и наш раздел уже разобрал главные: OCI-контейнеры в статье о контейнерах, Kubernetes API в статье о Kubernetes, S3-совместимое хранилище, SQL и открытые протоколы брокеров. Такие интерфейсы уменьшают объём переделок, но не гарантируют переносимости: отличаются расширения, IAM, сеть, лимиты, модели согласованности и эксплуатационные процедуры. Чем глубже собственные сервисы провайдера встроены в ядро, тем дороже выход. Симметричное предостережение: тотальная борьба с привязкой — тоже проигрышная стратегия: сведение всего к наименьшему общему знаменателю лишает систему полезных managed-возможностей, а «прослойка над всеми провайдерами» сама становится эксплуатационной ношей. Рабочее правило: ядро и данные — на достаточно переносимых интерфейсах; периферия — на чём удобнее, с записанной в архитектурном решении ценой выхода.

3. Мультиоблако: возможности и цена

«Разместимся у двух провайдеров — будет надёжнее» — гипотеза, которую нужно проверить по модели угроз и стоимости. Активное мультиоблако одной системы требует экспертизы по двум платформам, ограничивает выбор сервисов, создаёт межоблачный трафик и усложняет синхронизацию данных. Мультизонная или мультирегиональная архитектура у одного провайдера обычно проще и закрывает часть рисков, но не защищает от всех общих отказов: ошибок IAM и приложения, блокировки аккаунта, зависимости от общей управляющей плоскости или регионального сервиса. Мультиоблако может быть оправдано регуляторными требованиями, слияниями, нужной географией, особыми сервисами разных провайдеров или требованием пережить отказ самого поставщика. Разные системы в разных облаках — тоже мультиоблачный портфель организации, но не активная работа одной системы у двух провайдеров; эти варианты требуют разной сложности и не должны смешиваться в расчётах.

4. Миграция: порядок, который работает

У классификации стратегий семейства R есть несколько версий; например, актуальное руководство AWS использует семь. Сведём их к сути и типичным затратам:

• rehost («поднять и перенести»): перенос ВМ с минимальными изменениями сокращает объём переделок, но сохраняет прежнюю архитектуру и эксплуатационные ограничения; после переезда их стоимость в облачной тарифной модели может оказаться неожиданно высокой;
• replatform: точечные замены по пути — своя СУБД → managed, свои очереди → сервисные; объём переделок и выгоду оценивают для каждой системы;
• refactor: перестройка под облачную архитектуру из раздела 6 теоретической статьи требует проектирования и значительных изменений; её проводят там, где ожидаемая польза оправдывает эти затраты, обычно по частям;
• relocate: перенести поддерживаемую платформу или парк виртуальных машин на облачный вариант без изменения архитектуры приложения;
• и три организационных решения: retire (выключить ненужное), retain (пока оставить на месте), repurchase (заменить приложение готовым SaaS).

Порядок работ, выработанный отраслью: (1) инвентаризация — полный перечень систем с зависимостями (обнаружение зависимостей часто недооценивают: у «файлового обмена из 2009 года, о котором помнит один бухгалтер» есть много родственников); (2) пилот — некритичная, но настоящая система, на которой команда набирается опыта и калибрует смету; (3) волны переноса от периферии к ядру, со своей стратегией для каждой системы; (4) данные — отдельной дисциплиной: для больших работающих баз подходит связка из главы 10 курса — первоначальная копия снимка, догоняющая репликация изменений (CDC), сверка и переключение с коротким окном; (5) период двойной жизни — старый контур не выключается до сверки и стабилизации. Но само его существование ещё не обеспечивает откат: после появления записей в новой системе нужны обратная репликация, запрет записи на время возврата либо процедура согласования данных. План возврата репетируют до переключения и указывают в нём точку, после которой возможен только переход вперёд.

5. После переезда: стал ли ты облачным

Lift-and-shift — это начало, а не конец: перенос системы в облако ещё не означает, что она использует его свойства. Чек-лист адаптации превращает раздел 6 теоретической статьи в вопросы: можно ли заменить экземпляр без потери данных? соответствует ли масштабирование профилю нагрузки и действительно ли нужна автоматика? проверено ли поведение при отказе зоны? обоснованы ли самодельные компоненты, у которых есть подходящий managed-аналог? описана ли инфраструктура как код и проходит ли изменение ревью? Ответ «нет» не всегда ошибка: он может быть осознанным ограничением или переходным состоянием, которое нужно записать вместе с причиной и планом.

6. FinOps: куда утекают деньги

Облачный счёт отражает архитектуру, нагрузку и организационные решения; им управляют как измеряемой величиной: собирают данные, распределяют ответственность, оптимизируют и повторяют цикл.

• Видимость и распределение затрат. Аккаунты, проекты, подписки, группы ресурсов, теги и производные данные связывают расходы с командами, системами и окружениями. Не каждый вид затрат допускает одинаковую разметку, а общие расходы требуют отдельного правила распределения. Для бюджетов и аномальных расходов настраивают оповещения: обычное бюджетное предупреждение само по себе не ограничивает расход. Информационный отчёт по командам (showback) помогает принимать решения, но не гарантирует автоматического снижения счёта.
• Типичные утечки — список для первого аудита: забытые машины выключенных проектов; снимки и диски-сироты от удалённых ВМ; логи и метрики без срока хранения (жизненный цикл: горячее → холодное → удаление); межзонный и NAT-трафик, тарификацию которого не учли; ресурсы, размер которых выбрали «с запасом» и не пересматривали. Размер корректируют по фактическим метрикам и с запасом, обоснованным требованиями к производительности и отказам.
• Инструменты кривой нагрузки из теоретической статьи — в действии: обязательства по сроку или объёму для измеренного предсказуемого ядра, спот для прерываемой работы, выключение по расписанию стендов, нужных только в рабочие часы. Экономия от расписания относится к выключаемой вычислительной части, а хранение, лицензии и другие расходы могут сохраниться.
• Процесс. FinOps — не разовая чистка, а ритм: ежемесячный разбор счёта с владельцами систем, стоимость как критерий в архитектурных ревью (решение из главы 12 курса «каждая граница называет причину» получает финансовое измерение: каждая статья счёта называет владельца и причину).

7. Минимум безопасности, без которого нельзя

Теоретическая статья очертила разделённую ответственность; базовые меры на клиентской стороне заметно снижают риск: наименьшие привилегии для людей и сервисов, отдельные роли вместо общего администратора, краткоживущие учётные данные для автоматизации; секреты — в менеджере секретов, а не в коде и образах; многофакторная аутентификация на привилегированных и аварийных учётных записях; журналы аудита и оповещения средств безопасности; ревью инфраструктурного кода. Оповещение об аномальных расходах может дополнительно обнаружить майнинг или ошибочный запуск ресурсов, но не заменяет журналов и средств обнаружения атак. Этот абзац — гигиенический минимум, а не полная программа безопасности.

8. Практикум-оценки

Практикум расчётный: цифры условные, метод — переносимый.

Задание 1. Эластичность против ровности. Система в обычный день использует 10 серверов 12 часов и 2 сервера остальные 12 часов; три полных дня распродажи в году ей нужны 40 серверов. Получается 362 × (12 × 10 + 12 × 2) + 3 × 24 × 40 = 55 008 серверо-часов в год. Посчитайте: (а) собственную площадку на 40 машин — четверть цены оборудования в год плюс стойки, электричество, сеть и обслуживание; если нужен запас при отказе, учтите и его; (б) облако по цене p за серверо-час — 55 008 × p плюс диски, сеть и сервисы; (в) облако с обязательством на базовые 2 сервера — 17 520 часов по льготной цене и ещё 37 488 по обычной. Используйте сопоставимые мощности и выбранные вами цены. Точка равенства для нагрузки в H серверо-часов находится из H × p = годовая стоимость собственной площадки; затем проверьте, как её сдвигают скидки, персонал и стоимость простоя.

Задание 2. Стоимость выхода. Для гипотетической системы — 50 ТБ в объектном хранилище, 5 ТБ СУБД, 20 сервисов, из них 3 на проприетарном serverless — составьте смету ухода. Зафиксируйте дату, регион, валюту и источник тарифов; учтите чтение и передачу данных, временное двойное хранение и работу двух контуров, проверку целостности, изменение IAM и сети, переписывание непереносимых компонентов и обучение команды. Отдельно запишите неопределённость оценки и сравните смету с полной стоимостью входа, а не только с первоначальной миграцией.

Задание 3. Аудит утечек. Если у вас есть облачный аккаунт, сначала проведите чтение без изменений: найдите диски-сироты, снимки, нераспределённые расходы и логи без жизненного цикла, определите владельцев и оцените стоимость в месяц. Настройте бюджет с оповещением и проверьте получателей; помните, что предупреждение обычно не останавливает ресурсы. Удаляйте найденное только после подтверждения владельца, срока хранения и наличия нужной копии.

Задание 4*. План миграции на страницу. Для знакомой системы составьте одностраничный план: владелец и участники, зависимости, выбранная R-стратегия и причина, волны, RPO/RTO и допустимое окно, способ переноса и сверки данных, критерии приёмки. Для возврата укажите, как записи из нового контура попадут в старый, кто принимает решение и после какой точки возврат заменяется движением вперёд. Завершите критериями отключения старого контура и сроком хранения резервной копии.

Итоги

• Выбирают не провайдера, а набор критичных сервисов + модель эксплуатации; регуляторика — первый фильтр, стоимость выхода считается до входа.
• Привязка — кредит: открытые интерфейсы уменьшают цену выхода, но не устраняют различий в данных, сети, IAM и эксплуатации; тотальная борьба с привязкой тоже имеет цену.
• Активное мультиоблако одной системы добавляет отдельный класс сложности; его выбирают по модели угроз и требованиям, а не по одному слову «надёжность».
• Миграция: инвентаризация → пилот → волны → перенос и сверка данных → стабилизация; возможность отката после переключения требует отдельного потока данных или ограничения записи.
• FinOps: распределение затрат → поиск утечек → обязательства, спот-мощности и расписания по профилю нагрузки → регулярный разбор; бюджетное оповещение не ограничивает расход.
• Гигиена безопасности: наименьшие привилегии, краткоживущие учётные данные, секреты в менеджере, MFA, аудит и ревью инфраструктурного кода; аномалии счёта — дополнительный, а не основной сигнал.

Литература

1. FinOps Framework — модель практики управления технологической ценностью и затратами.
2. AWS Prescriptive Guidance: 7 Rs — один из вариантов классификации миграционных стратегий.
3. G. Hohpe, "Cloud Strategy," 2020 — редкая книга об облаках для архитекторов, а не администраторов.
4. Материалы нашего раздела: «Облака: устройство и модели», курс «Распределённые системы» — гл. 5 и 10 (репликация и CDC), гл. 12 (метод анкеты).