Разработка в Google Cloud: выбирайте модель работы, а не перечень служб

Google Cloud может сократить время, которое команда тратит на предоставление серверов, обслуживание типовой инфраструктуры и сборку платформ данных. Однако облако не решит, что именно должна гарантировать система. Успешное облачное решение начинается с пользователей, критических путей, данных, спроса, задержки, восстановления, безопасности, юрисдикции, возможностей команды и приемлемой стоимости эксплуатации. Службы подбирают уже по этим требованиям.

Главный выбор касается модели работы. Управляемая платформа Cloud Run оставляет небольшую область инфраструктуры для подходящих контейнерных служб. Google Kubernetes Engine даёт больше контроля над планированием и платформой, но требует более сильной ответственности за Kubernetes. Compute Engine сохраняет гибкость виртуальных машин вместе с обязанностью их администрировать. Управляемые базы данных, обмен сообщениями, аналитика, управление идентификацией, сеть и наблюдаемость передают Google отдельные виды работы, однако клиент по-прежнему отвечает за поведение приложения, управление данными, правила доступа, настройки, решения о восстановлении и реагирование на аварии.

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

Выбирайте службы Google Cloud по доказательствам о нагрузке

Cloud Run подходит службам HTTP без локального устойчивого состояния, API, потребителям событий, заданиям и веб-приложениям, которые предсказуемо запускаются и соответствуют его модели выполнения. Автоматическое масштабирование может следовать за спросом и уменьшать число экземпляров до нуля, а минимальное число экземпляров — сокращать задержку первого запуска. Устанавливайте параллельность, процессор, память, ограничения запросов и наибольшее число экземпляров по измерениям. Верхняя граница также защищает базы данных и зависимые API от резкого масштабирования. Храните устойчивое состояние вне контейнера, правильно завершайте работу, делайте операции безопасными для повторения и проверяйте повторные попытки.

Google Kubernetes Engine оправдывает стоимость платформы, когда нагрузки требуют API Kubernetes, особого планирования, сложного устройства служб, вспомогательных контейнеров, собственных контроллеров, переносимости или общей внутренней платформы с компетентными ответственными. До переноса определите ответственность за группу узлов, пространства имён, учётные сущности рабочих нагрузок, сеть, правила, обновления, резервные копии, ресурсы и дежурства. Не выбирайте GKE лишь потому, что система содержит несколько служб: Cloud Run или модульное приложение могут дать тот же результат для бизнеса с меньшей областью эксплуатации.

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

Выбирайте службы данных по способу доступа и восстановления. Cloud SQL поддерживает привычные реляционные нагрузки; высокая доступность, резервные копии, восстановление до момента времени, управление соединениями, технические работы и испытания восстановления должны быть определены явно. Firestore подходит для доступа к документам и приложений с немедленным обновлением, когда его запросы, согласованность, индексирование и модель стоимости соответствуют предметной области. BigQuery является аналитическим хранилищем, а не операционной базой данных для каждого экрана. Проектируйте наборы данных, разделение на части, группирование, сроки хранения, доступ, качество, происхождение и контроль стоимости запросов вокруг решений, которые должны поддерживать данные.

Используйте Pub/Sub, чтобы разъединить производителей и потребителей там, где задержанная или повторная доставка допустима и осознанно обрабатывается. Определите схемы сообщений, предположения о порядке, безопасное повторное выполнение, повторные попытки, правила недоставленных сообщений, повторное воспроизведение, сроки хранения, целевой размер очереди и расследование сообщений, постоянно вызывающих ошибку. «Опубликовано» не доказывает завершения операции бизнеса. Связывайте сообщения с результатами предметной области и обеспечьте сверку после частичного отказа.

Cloud Storage может хранить объекты, выгрузки, медиаданные, архивы и резервные копии, но каждое хранилище всё равно требует ответственного, места, сроков и жизненного цикла хранения, шифрования, запрета открытого доступа, работы с вредоносными файлами и правил удаления. Выбирайте регионы и несколько регионов по требованиям к задержке, доступности, месту хранения, восстановлению и передаче данных. У каждой новой службы должны быть названный ответственный, измеримая цель, поддерживаемые настройки и путь выхода или переноса.

Проектируйте синхронные API и асинхронные события как договоры бизнеса. Шлюз API или распределитель нагрузки может централизовать маршрутизацию, TLS, ограничения частоты и отдельные части подтверждения личности, но не исправит нечёткой ответственности или небезопасного разрешения доступа на сервере. Определите время ожидания, безопасность повторов, разделение результатов на страницы, квоты, развитие схемы, значение ошибок и совместимость потребителей. Кешируйте лишь при явных правилах актуальности, отмены, защиты данных и отказов. Размещайте CDN и средства на границе сети лишь там, где это оправдывают измеренные география, движение данных или характер атак.

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

Создайте средства контроля, которые делают управляемое облако пригодным к эксплуатации

Создайте базовую облачную среду до того, как продуктовые команды начнут заводить не связанные между собой проекты. Иерархия ресурсов Google Cloud помещает организацию над папками и проектами, благодаря чему разрешения IAM и правила организации наследуются. Стройте её по настоящему администрированию, средам, риску, оплате и делегированию, а не по декоративной организационной схеме. Отделяйте рабочую среду от нерабочих, централизуйте видимость оплаты и доступ к аудиту, определите создание проектов и ответственность за них и применяйте контрольные ограничения через код. Аварийный доступ должен быть узким, наблюдаемым и проверенным.

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

Проектируйте сеть по потокам доверия и движения данных: входящее и исходящее движение, DNS, доступ между службами, частные соединения со службами, распределение нагрузки, правила межсетевой защиты, гибридные соединения и контролируемое администрирование. Нахождение «внутри VPC» не является решением о разрешении. Проверяйте подлинность рабочих нагрузок и разрешайте запросы на уровнях службы и данных. Фиксируйте классы и потоки данных, чтобы место хранения, шифрование, сроки, выгрузку и обязанности поставщиков можно было проверить, а не предполагать.

Надёжность начинается с последствий для бизнеса и SLO. Решите, какие отказы должна выдерживать служба: экземпляра, зоны, региона, зависимости поставщика, неудачного развёртывания, потери учётных данных, повреждения данных или ошибки сотрудника. База данных с высокой доступностью не заменяет резервных копий, восстановления до момента времени, межрегионального планирования или сверки на уровне приложения. Измеряйте время восстановления и объём восстанавливаемых данных, действительно восстанавливая и переключая систему в реалистичных условиях. Задокументируйте ограниченный режим работы и полномочия на его введение.

Инфраструктура как код должна создавать воспроизводимые проекты, сети, личности, службы, оповещения и правила через проверенные изменения. CI/CD должен создавать один прослеживаемый пакет, проверять его происхождение и зависимости, испытывать поведение и настройки, перемещать между средами, постепенно развёртывать при оправданном риске и сохранять путь возврата или исправления. Избегайте процессов выпуска с постоянными учётными данными ответственного. Проверки правил и согласования должны соответствовать тяжести последствий, а не превращать каждое изменение в одинаковое ручное препятствие.

Наблюдаемость связывает диагностические данные с результатами пользователей и бизнеса. Используйте структурированные журналы, показатели, цепочки вызовов, записи аудита, отметки выпусков и идентификаторы связи; контролируйте чувствительное содержимое и сроки хранения. Панели показателей должны показывать поток запросов, задержку, ошибки, исчерпание ресурсов, актуальность, очередь, состояние зависимостей, расход допустимого запаса ошибок SLO и уместные расходы. Каждое оповещение требует ответственного, действенного порога, оперативной инструкции, порядка повышения уровня реагирования и пересмотра. Проверяйте, сохраняются ли диагностические данные во время отказов, которые нужно исследовать.

Стоимость является сигналом архитектуры. Назначайте проекты, метки, бюджеты и ответственных за расходы; отделяйте устойчивую основу от переменного спроса; следите за стоимостью единицы на клиента, запрос, задачу или набор данных рядом со счётом. Подбирайте размер ресурсов по фактическому использованию, ограничивайте автоматическое масштабирование, удаляйте неиспользованные ресурсы после определённого срока, контролируйте объём журналов и запросов, берите долгосрочные обязательства лишь при обоснованном спросе и включайте в полную стоимость поддержку, передачу данных, лицензии, перенос, восстановление и время инженеров. Сокращение затрат, которое нарушает SLO или перекладывает ручную работу на людей, не является оптимизацией.

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

Необходимость планировать ресурсы не исчезает с автоматическим масштабированием. Квоты проекта, наличие ресурсов в регионе, соединения с базой данных, ограничения скорости зависимых служб, диапазоны IP-адресов, очередь фоновых обработчиков и бюджет могут стать жёсткими границами. Испытывайте показательные пути под нагрузкой, моделируйте разветвление запросов, заранее резервируйте критические квоты и оповещайте до исчерпания. Проводите учебные отработки потери зависимости, ошибочных настроек, отзыва учётных данных, исчерпания квоты и ухудшения работы региона. Записывайте, какие средства сработали, какие предположения оказались ошибочными и какие шаги восстановления всё ещё зависят от одного человека.

Ответственный перенос начинается с исследования: учитывайте нагрузки, зависимости, данные, доступ, движение данных, расходы, лицензии, восстановление, эксплуатационные проблемы и сроки бизнеса. Отнесите каждый компонент к сохранению, выводу из работы, перемещению без изменений, переходу на другую платформу или перестройке. Сначала перенесите показательную сквозную часть вместе с выпуском, личностями, данными, наблюдением, резервным копированием, поддержкой и возвратом. Проверьте механизм в рабочей системе до массового переноса.

GARNO.TECH проектирует, создаёт, обновляет и эксплуатирует веб-приложения, API, продукты SaaS, процессы данных и корпоративные системы в Google Cloud. Сотрудничество может дать оценку архитектуры и базовой облачной среды, проверку Cloud Run или GKE, инфраструктуру как код, CI/CD и наблюдаемость, обновление баз данных и интеграций, отработку восстановления, контроль затрат или поэтапный перенос. Полезной исходной точкой является нагрузка, её пользователи, имеющиеся доказательства и отказ, которого бизнес не может допустить.

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

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

Держите архитектурные решения рядом с кодом и пересматривайте их после изменения спроса, регулирования, поведения служб или навыков команды. Для каждой управляемой зависимости задокументируйте формат выгрузки данных, границу замены, последовательность отключения и последствия недоступности поставщика. Переносимость — не абстрактное обещание запускать где угодно, а проверенная способность восстановить данные, сохранить поведение бизнеса и сменить зависимость за приемлемые для организации время и деньги. Проверьте важные предположения о выходе до того, как зависимость от поставщика станет аварией. Пересматривайте эти решения в устойчивом ритме и после каждого существенного сбоя, переноса, приобретения компании или изменения правовой ответственности.