Google Cloud (GCP)

01Ментальная модель: организация, проекты, регионы

Всё в GCP принадлежит какому-то проекту. Проект — это контейнер для ресурсов, биллинга и прав доступа: представьте его как одну квартиру в доме, со своими ключами и своим счётчиком электричества. Проекты можно складывать в папки (folders) под организацией, что позволяет компании применять политики (например, «никаких публичных бакетов») сразу ко всем командам. Распространённая схема — один проект на окружение: app-dev, app-staging, app-prod. Это даёт жёсткую стену между staging и продакшеном, отдельные квоты и понятный счёт по каждому окружению. Ресурсы работают в регионе (europe-west1, us-central1), а иногда в зоне внутри него (europe-west1-b). Выбирайте регион ближе к пользователям и держите приложение и его базу данных в одном регионе, потому что трафик между регионами стоит денег и добавляет задержку. Если сравнивать с AWS, проект GCP — это примерно аккаунт AWS, а организация GCP — примерно AWS Organizations.

• Организация → папки → проекты → ресурсы.
• Один проект на окружение — самая простая безопасная схема.
• Один регион для приложения и базы: ниже задержка, нет межрегионального egress.

02Вычисления: Cloud Run, GKE или Compute Engine

GCP даёт три основных способа запускать код. Compute Engine — обычные виртуальные машины, ближе всего к VPS: ОС, патчи и менеджер процессов вы ведёте сами. GKE — managed Kubernetes. В режиме Standard вы сами подбираете размер нод и управляете ими; в режиме Autopilot вы платите за CPU и память, которые запрашивают ваши поды, а нодами занимается Google. Cloud Run стоит уровнем выше: вы отдаёте ему контейнер, который слушает порт из переменной окружения PORT, и получаете HTTPS-эндпоинт, автомасштабирование по числу одновременных запросов, ревизии и разделение трафика. Cloud Run также запускает jobs (пакетные задачи, которые выполняются до завершения), функции (продукт, раньше называвшийся Cloud Functions, теперь называется Cloud Run functions) и worker pools для фоновой работы по pull-модели. Для типичного веб-API начинайте с Cloud Run. Переходите на GKE, когда нужно много сервисов с service mesh, нестандартная сеть или долгоживущие stateful-нагрузки, и на Compute Engine — когда нужен полный контроль над машиной.

03Деплой контейнера в Cloud Run

Самый быстрый путь — позволить Cloud Run собрать образ из исходников через Cloud Build и сохранить его в Artifact Registry (старый Container Registry уже закрыт). В реальных проектах собирайте образ в CI, пушьте его в Artifact Registry и деплойте именно этот тег образа. Дайте сервису собственный service account только с нужными ролями, храните секреты в Secret Manager и подключайтесь к Cloud SQL через встроенный коннектор. Ключевые флаги определяют стоимость и поведение: --min-instances держит тёплые инстансы (нет холодных стартов, но вы за них платите), --max-instances ограничивает и масштаб, и ваш счёт, а --concurrency задаёт, сколько запросов один инстанс обрабатывает одновременно. Node- и PHP-приложения обычно хорошо держат много одновременных запросов, так что значение по умолчанию 80 — разумная отправная точка.

1gcloud config set project app-prod
2gcloud services enable run.googleapis.com artifactregistry.googleapis.com
3 
4gcloud run deploy api \
5  --image=europe-west1-docker.pkg.dev/app-prod/apps/api:1.4.2 \
6  --region=europe-west1 \
7  [email protected] \
8  --set-secrets=DATABASE_URL=database-url:latest \
9  --add-cloudsql-instances=app-prod:europe-west1:main-db \
10  --min-instances=0 --max-instances=10 \
11  --concurrency=80 --cpu=1 --memory=512Mi \
12  --allow-unauthenticated

04Данные: Cloud SQL, Firestore, Cloud Storage и BigQuery

Cloud SQL — это managed PostgreSQL, MySQL или SQL Server: Google берёт на себя патчи, автоматические бэкапы, point-in-time recovery и, по желанию, высокую доступность со standby в другой зоне. Есть редакции Enterprise и Enterprise Plus; Plus даёт более быстрый failover и больше производительности за более высокую цену. AlloyDB — совместимый с Postgres движок Google для более тяжёлых нагрузок. Firestore — serverless документная база данных, популярная в мобильных приложениях. Cloud Storage хранит файлы (загрузки, бэкапы, статику) в бакетах с классами хранения от Standard до Archive. BigQuery отличается от всего этого: это колоночное хранилище для аналитики, а не для транзакций вашего приложения. Вы загружаете или стримите в него события и выполняете SQL по огромным таблицам. On-demand-тариф берёт плату за каждый просканированный терабайт, поэтому SELECT * по широкой таблице буквально дорог; выбирайте только нужные колонки и партиционируйте таблицы по дате.

• Данные приложения → Cloud SQL (или AlloyDB). Файлы → Cloud Storage.
• Аналитика и отчёты → BigQuery, данные из приложения или через экспорт.
• У Cloud SQL нет бесплатного уровня: даже самый маленький инстанс тарифицируется каждый час своего существования.

05IAM: кто что может делать

IAM отвечает на один вопрос: какой principal (пользователь, группа или service account) имеет какую роль на каком ресурсе. Роли — это наборы разрешений, например roles/run.invoker или roles/cloudsql.client. Избегайте базовых ролей Owner, Editor и Viewer для всего, кроме мелких экспериментов: они слишком широкие. Дайте каждой нагрузке свой service account и выдавайте ему predefined-роли на самом узком возможном уровне — на один бакет или секрет, а не на весь проект. Главное правило безопасности в GCP: не создавайте скачиваемые ключи service account. JSON-файл ключа — это долгоживущий пароль, который в итоге оказывается в репозиториях и на ноутбуках. Код, работающий в Google Cloud, автоматически получает учётные данные от привязанного service account, а CI-системы вроде GitHub Actions должны использовать Workload Identity Federation, которая обменивает короткоживущий OIDC-токен на учётные данные Google. Именно поэтому в новых организациях создание ключей по умолчанию запрещено политикой.

06Советы для продакшена и ценовые ловушки

GCP тарифицирует большинство вещей посекундно — это прекрасно, пока не работает что-то, о чём вы забыли. В первый же день настройте бюджет с алертами (бюджеты предупреждают, но не останавливают траты). Типичные сюрпризы: инстансы Cloud SQL тарифицируются круглосуточно, даже когда приложение простаивает; min-instances в Cloud Run оплачиваются во время простоя; у Cloud NAT и балансировщиков есть почасовая плата; исходящий трафик в интернет оплачивается за каждый ГБ; а on-demand-запросы в BigQuery оплачиваются по просканированным байтам, так что дашборд, который каждую минуту обновляет SELECT *, может стоить дороже всего приложения. Логирование — ещё одна ловушка: Cloud Logging берёт плату за приём логов сверх бесплатного лимита, поэтому не логируйте полные тела запросов на уровне debug в продакшене. Always-free-уровень покрывает небольшое использование Cloud Run, Cloud Storage, BigQuery и одну маленькую VM, а новые аккаунты получают пробный кредит, но прочитайте лимиты, прежде чем на них рассчитывать.

07Cloud Run изнутри: concurrency, выделение CPU и холодные старты

Cloud Run масштабируется по одновременным запросам, а не только по CPU. Если concurrency равна 80 и в обработке 400 запросов, он стремится к примерно пяти инстансам. Каждый инстанс работает в песочнице на базе gVisor (среда выполнения второго поколения даёт полную совместимость с Linux и более быстрые CPU и сеть). У биллинга два режима. Request-based-биллинг берёт плату за CPU и память только пока инстанс обрабатывает запрос, а между запросами CPU урезается почти до нуля, поэтому таймеры, потребители очередей и работа в стиле «запустил и забыл» после ответа могут просто зависнуть. Instance-based-биллинг (раньше — «CPU always allocated») берёт плату за всё время жизни инстанса по более низкой ставке и позволяет выполнять фоновую работу. Холодные старты возникают из-за скачивания образа и запуска рантайма; сокращайте их маленькими образами, ленивой инициализацией, startup CPU boost и, где важна задержка, минимальным числом инстансов в один-два.

1# Background-friendly service: instance billing + warm instance
2gcloud run services update worker-api \
3  --region=europe-west1 \
4  --no-cpu-throttling \
5  --cpu-boost \
6  --min-instances=1 \
7  --execution-environment=gen2

08Сеть: VPC, приватный доступ и egress

VPC в GCP глобальна: одна сеть может иметь подсети во многих регионах, в отличие от AWS, где VPC региональна. Cloud Run по умолчанию находится вне вашей VPC; чтобы достучаться до приватных ресурсов (Cloud SQL по private IP, Memorystore Redis, внутренние VM), используйте Direct VPC egress — он подключает сервис к подсети без VM старого коннектора Serverless VPC Access. Исходящие вызовы в интернет, которые должны идти с фиксированного IP (allowlist у партнёров), проходят через Cloud NAT с зарезервированным адресом. Private Service Connect и Private Google Access позволяют нагрузкам обращаться к Google API без публичных IP. Для входящего трафика глобальный внешний Application Load Balancer даёт один anycast IP, managed-сертификаты, Cloud CDN и Cloud Armor (WAF и rate limiting) перед Cloud Run, GKE или бакетами. У каждого из этих компонентов своя почасовая и погигабайтная плата, поэтому нарисуйте путь трафика до того, как строить.

09Политики организации, audit-логи и ограничители

В масштабе компании важные механизмы контроля находятся выше проектов. Ограничения organization policy могут запрещать создание ключей service account, ограничивать расположение ресурсов определёнными регионами, блокировать публичные IP на VM, требовать uniform bucket-level access и запрещать публичный доступ. Cloud Audit Logs бесплатно записывают административные действия и могут записывать доступ к данным (за дополнительную плату) для compliance. Поместите чувствительные проекты за VPC Service Controls, чтобы снизить риск утечки данных: даже украденные учётные данные не позволят скопировать датасет BigQuery в проект за пределами периметра. В IAM-привязках используйте группы, а не отдельных пользователей, и пересматривайте выданные права с IAM Recommender, который предлагает убрать ни разу не использованные разрешения. Инфраструктура должна быть в Terraform с remote state в бакете, чтобы каждое изменение проходило ревью, а не накликивалось в консоли.