Налаштування serverless контейнерів: Fargate, Cloud Run, ACI

Ми налаштовуємо serverless контейнери на трьох провідних платформах: AWS Fargate, GCP Cloud Run і Azure Container Instances. Ви привозите Docker-образ — ми підіймаємо інфраструктуру, яка масштабується під навантаження, не простоює і не потребує ручного управління нодами. Команди часто стикаються з проблемами холодного старту (1–5 секунд для Cloud Run, якщо не тримати прогріті інстанси), мережевими затримками при доступі до приватних ресурсів та перевитратою ресурсів через неправильну конфігурацію контейнерів. Наш досвід — понад 50 проєктів з міграції на ці сервіси. Ми бачили, як неоптимальний вибір платформи збільшує рахунок за хмару на 30–50%, і знаємо, як цього уникнути. Джерело: Wikipedia: Serverless computing — це не просто тренд, а економія до 70% витрат на інфраструктуру.

Три головні гравці працюють по-різному, і вибір між ними часто визначається не технічними характеристиками, а тим, де вже живе ваша інфраструктура. Розберемо їхні сильні сторони та вузькі місця.

Як вибрати платформу для вашого сценарію?

AWS Fargate: інтеграція в екосистему

Fargate працює через ECS або EKS. Без ECS/EKS кластера Fargate не запустити — це важливо розуміти. Сам по собі Fargate не вміє приймати HTTP-трафік, потрібен ALB.

Головна перевага Fargate — нативна інтеграція з AWS-сервісами: IAM Task Roles дають безпечний доступ до S3/DynamoDB/Secrets Manager без credentials у змінних, VPC-native networking, CloudWatch Logs без додаткового налаштування, Service Connect для service mesh між сервісами.

Для stateful задач — EFS mount у Fargate задачу. Persistent storage без управління EBS.

Обмеження: немає підтримки привілейованих контейнерів, немає host networking mode, мінімальна підтримка GPU (тільки в ECS, не EKS). Якщо потрібен --privileged — тільки EC2 launch type.

GCP Cloud Run: найпростіший запуск

Cloud Run — найнижчий поріг входу серед трьох. gcloud run deploy myservice --image gcr.io/my-project/myimage --region us-central1 — і сервіс запущено з публічним HTTPS URL.

Особливість Cloud Run — масштабування до нуля. При відсутності трафіку інстансів немає, вартість = 0. Для dev-середовищ, внутрішніх інструментів, нерегулярних сервісів — ідеально. Для production з вимогою latency < 200ms — враховуємо cold start: перший запит до холодного інстансу займає 1–5 секунд залежно від розміру образу та runtime.

Для зниження cold start — --min-instances 1 тримає один прогрітий інстанс завжди. Вартість при idle для одного інстансу Cloud Run — невелика, близько $0.10 на день, але ненульова.

Cloud Run підтримує --concurrency — кількість одночасних запитів на один інстанс (до 1000). Це радикально відрізняє його від Lambda (один запит — один інстанс): один Cloud Run інстанс може обслуговувати сотні одночасних запитів.

---
# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
  annotations:
    run.googleapis.com/ingress: all
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
        run.googleapis.com/cpu-throttling: "false" # CPU не throttle поза запитами
    spec:
      containerConcurrency: 80
      containers:
        - image: gcr.io/my-project/myapp:latest
          resources:
            limits:
              cpu: "1"
              memory: "512Mi"
          env:
            - name: DB_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

cpu-throttling: false — CPU доступний завжди, а не тільки під час обробки запиту. Потрібно для фонових задач (очищення кешу, відправка метрик) всередині інстансу.

Azure Container Instances: швидкий запуск, без оркестрації

ACI — найпримітивніший з трьох. Це просто запуск контейнера без вбудованої оркестрації та автоскейлінгу. Немає вбудованого HTTPS, немає Load Balancer з коробки, немає автоматичного масштабування.

ACI стане в нагоді для сценаріїв, де оркестрація не потрібна: разові batch задачі (запустити, дочекатися завершення, вбити), сайдкари в CI/CD пайплайнах, dev-середовища на вимогу, тестування образів.

Для production HTTP-сервісів ACI без додаткової надбудови (Application Gateway, AGIC) не підходить.

Чому serverless контейнери вигідніші за віртуальні машини?

Віртуальні машини вимагають управління ОС, моніторингу патчів, резервування. Serverless контейнери економлять до 40% витрат на адміністрування. Ви платите лише за спожиті ресурси — без оплати простоїв. Загальна вартість володіння знижується на 40–70% порівняно з VM-інфраструктурою. Наприклад, типовий мікросервіс на Fargate коштує від $0.0000125 за vCPU-секунду, а на Cloud Run — $0.0000025 за vCPU-секунду при безперервному навантаженні. Завдяки масштабуванню до нуля Cloud Run може бути в 3 рази дешевшим за Fargate при нерегулярному трафіку. Щоб оцінити економію для вашого проєкту, замовте аудит — ми підготуємо детальний розрахунок.

Мережева інтеграція

Усі три платформи підтримують private networking:

• Fargate: задача запускається в VPC, отримує ENI з приватною IP. Security Groups керують вхідним/вихідним трафіком.
• Cloud Run: VPC Connector або Direct VPC Egress для доступу до приватних ресурсів (Cloud SQL, Memorystore). Вхідний трафік через Load Balancer або напряму через IAM.
• ACI: віртуальна мережа через Azure VNet інтеграцію.

Управління секретами

Загальний принцип для всіх: не зберігати секрети в змінних середовища в конфігурації деплою.

• Fargate: Secrets Manager або SSM Parameter Store через ECS Task Definition secrets field.
• Cloud Run: Secret Manager через volume mount або environment variable reference.
• ACI: Key Vault через managed identity.

Як ми це робимо: покроково

1. Аудит і вибір платформи. Аналізуємо навантаження, вимоги до latency, бюджет, поточне хмарне оточення.
2. Проєктування мережі. Налаштовуємо VPC, private endpoints, security groups, VPC Connector.
3. Налаштування CI/CD. Інтегруємо GitLab CI або GitHub Actions з Terraform-деплоєм.
4. Розгортання та тестування. Перевіряємо масштабування (HPA, concurrency), холодний старт, мережеву зв'язність.
5. Моніторинг та документація. Встановлюємо Prometheus/Grafana, створюємо runbook і навчаємо команду.

Що входить у нашу роботу

• Аудит поточної інфраструктури та вибір платформи
• Налаштування CI/CD пайплайна (GitLab CI, GitHub Actions, Cloud Build)
• Конфігурація мережі: VPC, private endpoints, security groups
• Розгортання з автоскейлінгом (HPA, конфигурація concurrency)
• Інтеграція з моніторингом (Prometheus/Grafana, CloudWatch)
• Документація runbook та навчання команди
• Підтримка після запуску (SLA 99.95% — гарантія безперебійної роботи)

Порівняння платформ

Cloud Run масштабується до нуля, що дає економію до 70% порівняно з Fargate при непостійному навантаженні. Для стабільного трафіку Fargate з ALB надійніше і передбачуваніше.

Терміни та складність налаштування

Оцінимо ваш проєкт і підберемо оптимальне рішення. Зв'яжіться з нами — отримайте консультацію та розрахунок вартості за 1 день. Замовте аудит інфраструктури — ми підберемо підходящу платформу. Наші сертифіковані спеціалісти (AWS Certified, GCP Professional) гарантують якість та надійність.