Зачем нужны зоны (zones) в микросервисной архитектуре?

В контексте микросервисной архитектуры, зоны (zones) — это логическое или физическое группирование сервисов, развернутых в инфраструктуре, обычно для целей изоляции отказов, управления трафиком и соответствия регуляторным требованиям. В облачных провайдерах они часто соответствуют зонам доступности (Availability Zones, AZ).

Основные цели использования зон:

1. Повышение отказоустойчивости (Resilience): Размещение реплик сервиса в разных физически изолированных зонах доступности гарантирует, что отказ одной зоны (из-за проблем с питанием, сетью или оборудованием) не приведет к полной недоступности системы. Kubernetes, например, может автоматически распределять поды (pods) по разным зонам.
2. Снижение задержки (Latency): Сервисы, которым критически важна низкая задержка при общении друг с другом, можно размещать в одной зоне, чтобы минимизировать сетевые hop'ы. Пользовательский трафик можно маршрутизировать в ближайшую географическую зону (регион).
3. Изоляция по признакам:
   • Безопасность: Сервисы, обрабатывающие конфиденциальные данные (например, платежи), можно изолировать в отдельную зону с более строгими сетевыми политиками (security groups, NACLs).
   • Соглашения об уровне обслуживания (SLA): Критичные сервисы с высоким SLA разворачиваются в нескольких зонах, в то время как менее важные могут работать в одной.
   • Соответствие требованиям (Compliance): Данные, подпадающие под определенную юрисдикцию (например, GDPR), должны оставаться в конкретном географическом регионе (зоне).

Пример настройки в Kubernetes (распределение по зонам доступности):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cart-service
spec:
  replicas: 6 # 2 пода на каждую из 3-х зон
  selector:
    matchLabels:
      app: cart
  template:
    metadata:
      labels:
        app: cart
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - cart
              topologyKey: topology.kubernetes.io/zone # Ключевой параметр: распределение по зонам
      containers:
      - name: cart
        image: my-registry/cart-service:v1.2.3
---
apiVersion: v1
kind: Service
metadata:
  name: cart-service
spec:
  selector:
    app: cart
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer
  externalTrafficPolicy: Local # Сохранение source IP и маршрутизация трафика внутри зоны, где он принят

Архитектурные паттерны с использованием зон:

• Active-Active: Сервис работает во всех зонах одновременно, трафик распределяется между ними.
• Active-Passive (Pilot Light / Warm Standby): Основная рабочая нагрузка в одной зоне, резервная копия с минимальными ресурсами в другой, готовая к масштабированию при сбое.

Использование зон — это неотъемлемая часть проектирования отказоустойчивых, масштабируемых и безопасных облачных нативных приложений.