DevOps живет в состоянии непрерывного развития — стоит только освоить один инструмент, появляется три новых, а у проверенных решений открываются неожиданные грани.

Мы запускаем серию глубоких технических погружений: каждую неделю берем одну тему и докапываемся до сути, раскладывая по полочкам все нюансы — от service mesh и мониторинга до шардирования и распределенных хранилищ.

А между техническими постами поговорим о карьерном росте, профессиональном выгорании и культуре DevOps в эпоху распределенных команд и удаленной работы.

Эту неделю мы посвятим Service Mesh Architecture — разберем, как правильно готовить микросервисы с Istio и Linkerd, настраивать трассировку и балансировку, и почему service mesh — это не всегда серебряная пуля.

🏴‍☠️ @happy_devops

Service Mesh в микросервисной архитектуре часто сравнивают с нервной системой организма. И не зря — он контролирует взаимодействие сервисов, следит за их здоровьем и реагирует на проблемы. Только вот внедряют его обычно, когда организм уже болен: микросервисы размножились, латентность выросла, а в логах творится полный хаос.

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

Представьте себе крупный интернет-магазин. Заказ проходит через десяток сервисов: корзина, платежи, склад, доставка, уведомления... И каждый сервис должен знать, как общаться с остальными. Где они находятся, какие у них эндпоинты, как авторизоваться, что делать при таймаутах. Добавьте сюда версионирование API, балансировку нагрузки, и мониторинг — получается гремучая смесь.

Service Mesh берет эту головную боль на себя. Он добавляет к каждому сервису прокси-компонент (sidecar), который перехватывает весь входящий и исходящий трафик. Теперь сервисам не нужно знать друг о друге — они общаются через прокси, а уже он решает, куда и как доставить запрос.

Звучит как еще один слой сложности? Да, но эта сложность того стоит. Service Mesh дает готовые решения для типичных проблем распределенных систем. Трассировка запросов? Включается одним конфигом. Защита от каскадных отказов? Circuit breaker из коробки. Постепенный переход на новую версию сервиса? Canary deployment без единой строчки кода.

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

А вот если у вас правда болит голова от управления трафиком между сервисами — Service Mesh может стать тем самым обезболивающим. В следующих постах разберем конкретные примеры и поговорим, как готовить Service Mesh правильно.

🏴‍☠️ @happy_devops

Борьба с латентностью в микросервисной архитектуре — это вечная битва. Service Mesh и конкретно Istio дают мощный арсенал инструментов для этой войны. Только вот документация Istio напоминает инструкцию к боевому истребителю — куча кнопок, а как их правильно нажимать, не всегда понятно.

Начнем с основ конфигурации timeout и retry. В реальном мире сервисы тормозят, падают и теряют пакеты. Сетевые таймауты и повторные попытки — это наша первая линия обороны. Вот базовая конфигурация VirtualService для управления таймаутами:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
  - payment-service
  http:
  - route:
    - destination:
        host: payment-service
        subset: v1
    timeout: 3s
    retries:
      attempts: 3
      perTryTimeout: 1s
      retryOn: connect-failure,refused-stream,5xx

Этот конфиг говорит: "Если платежный сервис не ответил за 3 секунды или вернул ошибку — делаем еще три попытки, каждая по секунде". Обратите внимание на retryOn — здесь перечислены условия для повторных попыток. В продакшене часто добавляют gateway-error и reset для борьбы с сетевыми глюками.

Но одни таймауты не спасут от каскадных отказов. Тут в бой вступает circuit breaker. Его задача — вовремя понять, что сервис болеет, и перестать его мучить запросами. Настраивается через DestinationRule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 10

Тут мы говорим: "После 5 ошибок подряд в течение 10 секунд выключаем проблемный под на 30 секунд". MaxEjectionPercent защищает от ситуации, когда все поды вырублены — минимум 50% останутся в строю. А connectionPool не дает завалить сервис лавиной запросов.

Теперь самое интересное — rate limiting. В продакшене часто бывает, что один сервис-сосед начинает долбить твой сервис миллионом запросов в секунду. Rate limiting помогает зарубить такие атаки на корню:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: payment-ratelimit
spec:
  workloadSelector:
    labels:
      app: payment-service
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typedConfig:
          "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          statPrefix: http_local_rate_limiter
          tokenBucket:
            maxTokens: 1000
            tokensPerFill: 100
            fillInterval: 1s
          filterEnabled:
            runtime_key: local_rate_limit_enabled
            default_value:
              numerator: 100
              denominator: HUNDRED

Этот монстр ограничивает входящий трафик до 100 запросов в секунду с возможностью буста до 1000 запросов. Важный момент — rate limiting лучше делать на уровне отдельных эндпоинтов, а не всего сервиса. Какие-то API могут быть тяжелыми и требовать жестких ограничений, а какие-то — легкими и способными переварить больше трафика.

Для мониторинга всей этой красоты нужны правильные метрики. Базовый набор:
- istio_request_duration_milliseconds — латентность запросов
- istio_requests_total — количество запросов с разбивкой по кодам ответа
- istio_request_bytes — размер запросов
- envoy_cluster_upstream_rq_pending_overflow — сработавшие circuit breaker
- envoy_cluster_upstream_rq_retry — количество повторных попыток
- envoy_http_ratelimit_total_requests_denied — отклоненные rate limiter запросы

🏴‍☠️ @happy_devops

Алерты стоит ставить не только на высокую латентность, но и на аномальное количество ретраев и срабатываний circuit breaker. Это часто помогает поймать проблемы до того, как они выльются в полноценный инцидент.

И последний совет: не включайте все фичи сразу. Начните с базовых таймаутов и ретраев, убедитесь что все работает как надо. Потом добавьте circuit breaker, настройте его пороги. И только потом, если нужно, переходите к rate limiting. Постепенное внедрение позволит избежать ситуации, когда Service Mesh сам становится источником проблем.

🏴‍☠️ @happy_devops

В современном Service Mesh Envoy — это основная рабочая сила, а Istio — генерал, который командует армией прокси-серверов. Каждый сервис получает свой персональный Envoy (sidecar), а Istio через control plane раздает этим Envoy указания: кого пускать, кого блокировать, как балансировать нагрузку.

Когда микросервис хочет поговорить с соседом, его запрос сначала попадает в локальный Envoy. Тот сверяется с картой маршрутов от Istio и принимает решение: пропустить запрос, перенаправить на другую версию сервиса или вообще отклонить. Такая архитектура превращает сеть микросервисов в управляемую структуру — какие бы правила не придумал оператор, они моментально распространяются на все прокси.

Вот пример базовой конфигурации Envoy для обработки входящего HTTP-трафика:

static_resources:
  listeners:
  - name: http_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  
  clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

А вот как настраивается более продвинутая конфигурация с retry policy и circuit breaker:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 1000
          max_pending_requests: 1000
          max_requests: 1000
          max_retries: 3
    retry_policy:
      retry_on: connect-failure,refused-stream,unavailable
      num_retries: 3
      per_try_timeout: 1s
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

В финальной конфигурации часто добавляют health checks и outlier detection:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    health_checks:
      - timeout: 1s
        interval: 5s
        unhealthy_threshold: 3
        healthy_threshold: 1
        http_health_check:
          path: "/health"
    outlier_detection:
      consecutive_5xx: 5
      base_ejection_time: 30s
      max_ejection_percent: 50

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

В итоге Service Mesh на базе Istio и Envoy — это как операционная система для микросервисов. Разработчикам не нужно думать о network resilience, service discovery или сборе метрик. Все эти задачи делегированы инфраструктурному слою. А значит, команды могут сфокусироваться на бизнес-логике, не изобретая велосипеды для базовых сетевых операций.

🏴‍☠️ @happy_devops

Распределенная трассировка в микросервисной архитектуре — это как GPS для запросов. Только вместо карты города перед нами карта вызовов между сервисами. И если без GPS еще можно как-то найти нужную улицу, то без трейсинга в распределенной системе мы как слепые котята.

Service Mesh и конкретно Istio + Envoy дают мощный инструментарий для трассировки. Весь трафик проходит через прокси, а значит, мы можем видеть каждый запрос, его путь и время выполнения. Но настроить это все правильно — задача нетривиальная.

Начнем с базовой конфигурации. В Istio включаем трейсинг через конфиг:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
        zipkin:
          address: jaeger-collector.observability:9411

Тут мы говорим: "Собирай все запросы (sampling: 100) и отправляй их в Jaeger через Zipkin протокол". На проде sampling обычно ставят 1-10%, иначе можно захлебнуться в данных.

Теперь нужно научить наши сервисы пробрасывать trace контекст. Istio автоматически добавляет заголовки x-request-id, x-b3-traceid и другие. Но для полной картины стоит добавить инструментацию в код:

from opentelemetry import trace
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()

@app.route('/api/order')
def create_order():
    tracer = trace.get_tracer(__name__)
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order_type", "regular")
        result = process_order()
        return result

Такой код не только подхватит trace контекст из заголовков, но и добавит свои спаны с дополнительной информацией. В Jaeger мы увидим не просто вызовы между сервисами, а конкретные операции внутри каждого сервиса.

А вот пример конфигурации для отлова проблем производительности:

apiVersion: networking.istio.io/v1alpha3
kind: Telemetry
metadata:
  name: trace-sampling
spec:
  selector:
    matchLabels:
      app: orders
  tracing:
  - randomSamplingPercentage: 100.0
    customTags:
      http.status_code:
        header:
          name: :status
          defaultValue: "200"
      request.size:
        header:
          name: content-length
          defaultValue: "0"

Здесь мы добавляем кастомные теги для каждого трейса — HTTP статусы и размеры запросов. Это поможет быстрее находить проблемные паттерны.

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

И последний совет — не пытайтесь трейсить все подряд. Определите критичные бизнес-операции и сфокусируйтесь на них. Иначе рискуете утонуть в море бесполезных данных.

🏴‍☠️ @happy_devops

Service Mesh — не серебряная пуля. После недели глубокого погружения в тему становится очевидно: это мощный инструмент, который может как решить кучу проблем, так и создать новые.

С одной стороны, Service Mesh дает нам богатый набор фич из коробки: трассировку запросов, умную балансировку нагрузки, гранулярный контроль трафика. Envoy в качестве прокси показывает отличную производительность, а Istio берет на себя всю головную боль с конфигурацией и обновлением правил. Добавьте сюда автоматический сбор метрик, защиту от каскадных отказов и canary deployments — получается внушительный список преимуществ.

Но у каждого плюса есть своя цена. Дополнительный прокси-слой — это overhead по CPU и памяти. Control plane требует отдельных ресурсов и внимания. Отладка проблем становится сложнее, потому что теперь между сервисами есть еще один слой абстракции. А уж если что-то пошло не так с самим Service Mesh — готовьтесь к веселому дебагу.

В итоге все сводится к старому доброму "зависит от контекста". Если у вас десяток микросервисов и простая топология — Service Mesh может оказаться из пушки по воробьям. Но если счет идет на сотни сервисов, если вам нужен серьезный мониторинг и контроль трафика — инвестиция в Service Mesh окупится сторицей.

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

🏴‍☠️ @happy_devops

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

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

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

NoSQL решения вроде MongoDB созданы для работы с неструктурированными данными и горизонтального масштабирования. Они прекрасно справляются с большими нагрузками, но теряют эффективность при сложных связанных запросах.

Колоночные хранилища ClickHouse и Vertica раскрывают свой потенциал в аналитических системах. Они обрабатывают огромные массивы данных на лету при условии правильно спроектированной схемы и настроенных агрегаций.

Time-series базы данных InfluxDB и Prometheus специализируются на работе с метриками и логами. Их внутренняя архитектура оптимизирована под запись и чтение временных рядов, что делает их незаменимыми для мониторинга.

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

Репликация и бэкапы — основа отказоустойчивости. В штатном режиме они кажутся лишней перестраховкой, но в критической ситуации становятся последней линией защиты данных.

На этой неделе разберем тонкости настройки разных типов баз: от PostgreSQL до MongoDB и Elasticsearch. Поговорим про инструменты диагностики, разберем популярные проблемы и обсудим стратегии масштабирования.

🏴‍☠️ @happy_devops

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

PostgreSQL предлагает несколько типов индексов, и каждый подходит для своих сценариев. B-tree индексы — стандартный выбор для большинства случаев. Они эффективны для поиска по точному совпадению и для диапазонных запросов. GiST индексы незаменимы для геоданных и полнотекстового поиска. Hash индексы работают только с равенством, зато делают это максимально быстро.

Создание индекса — это только начало пути. Планировщик запросов не всегда использует доступные индексы, особенно если статистика устарела или запрос написан неоптимально. Команда EXPLAIN ANALYZE показывает реальный план выполнения запроса. Если вместо Index Scan видите Sequential Scan — самое время разобраться, почему индекс игнорируется.

При создании составных индексов порядок колонок критически важен. Индекс по (last_name, first_name) поможет найти всех однофамильцев, а вот индекс по (first_name, last_name) для такого запроса будет бесполезен. Первая колонка должна быть самой селективной — той, что лучше всего сужает результаты поиска.

Не стоит индексировать все подряд — это замедляет операции вставки и обновления. Каждый индекс нужно поддерживать в актуальном состоянии, что требует дополнительных ресурсов. Особенно осторожно нужно подходить к индексам на часто изменяемых колонках.

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

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

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

Мониторинг использования индексов не менее важен, чем их создание. pg_stat_user_indexes показывает, как часто используется каждый индекс. Если индекс не используется месяцами, а места занимает много — стоит задуматься о его удалении.

🏴‍☠️ @happy_devops

EXPLAIN — основной инструмент для отладки производительности запросов в PostgreSQL. За сухими цифрами и техническими терминами в его выводе скрываются истории о том, как база данных пытается максимально быстро найти нужные данные.

Планировщик PostgreSQL выбирает путь выполнения запроса на основе статистики и эвристик. Sequential Scan — самый простой способ, перебор всех строк таблицы. Index Scan использует индекс и подходит для точечных запросов. Bitmap Scan комбинирует несколько индексов, собирая битовую карту подходящих строк.

Parallel Sequential Scan означает, что база распределила нагрузку между несколькими процессами. Звучит круто, но если запрос часто выполняется — лучше помочь базе правильным индексом. Nested Loop, Hash Join и Merge Join — разные стратегии объединения таблиц, каждая со своими сильными сторонами.

EXPLAIN ANALYZE не просто показывает план, но и реально выполняет запрос. В выводе появляются actual time и actual rows — реальное время выполнения и количество обработанных строк. Если цифры сильно отличаются от estimated — планировщик работает с устаревшей статистикой.

Высокие значения в startup time говорят о длительной подготовке операции. Большая разница между loops planned и loops actual намекает на проблемы с кардинальностью. А buffers shared hit против buffers shared read показывает, насколько эффективно работает кэш.

Partial и parallel стоит внимательно изучить. Partial Mode означает, что база выбрала только часть данных. А чем больше workers запущено в parallel, тем важнее следить за нагрузкой на CPU и диск — параллельное выполнение требует ресурсов.

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

И последнее: EXPLAIN ANALYZE реально выполняет запрос. На больших таблицах это может занять много времени. Если нужно только проверить план — используйте обычный EXPLAIN. А для анализа боевых систем присмотритесь к auto_explain, он покажет планы запросов прямо в логах.

🏴‍☠️ @happy_devops

Как EXPLAIN помогает находить проблемы в типичных запросах.

Индексы и EXPLAIN — главные инструменты для отладки производительности в PostgreSQL. Планировщик выбирает путь выполнения запроса на основе статистики, а EXPLAIN показывает, насколько удачным был этот выбор.

Возьмем типичный запрос поиска заказов за последний месяц с джойном на таблицу пользователей:

EXPLAIN ANALYZE
SELECT o.id, o.created_at, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days'
  AND o.status = 'completed';

->  Hash Join  (cost=19.15..729.45 rows=238 width=80) (actual time=0.432..5.512 rows=245)
      Hash Cond: (o.user_id = u.id)
      ->  Seq Scan on orders o  (cost=0.00..685.20 rows=238 width=56)
            Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval))
      ->  Hash  (cost=12.40..12.40 rows=540 width=36)
            ->  Seq Scan on users u  (cost=0.00..12.40 rows=540 width=36)

Sequential Scan в плане запроса — первый звоночек. База читает всю таблицу orders, чтобы найти записи за последний месяц. Создадим индекс по дате создания и статусу:

CREATE INDEX idx_orders_date_status ON orders(created_at, status);

EXPLAIN ANALYZE SELECT ...
->  Hash Join  (cost=19.15..129.45 rows=238 width=80) (actual time=0.132..0.512 rows=245)
      Hash Cond: (o.user_id = u.id)
      ->  Index Scan using idx_orders_date_status on orders o  (cost=0.00..85.20 rows=238 width=56)
            Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval))
      ->  Hash  (cost=12.40..12.40 rows=540 width=36)
            ->  Seq Scan on users u  (cost=0.00..12.40 rows=540 width=36)

Index Scan и время выполнения упало в 10 раз — именно то, что нужно. Но обратите внимание на Seq Scan для таблицы users. База все еще читает ее целиком, хотя мы достаем только email. Самое время для покрывающего индекса:

CREATE INDEX idx_users_email ON users(id) INCLUDE (email);

EXPLAIN не просто показывает план, но и помогает его улучшить. Главное — понимать, что стоит за каждой строчкой его вывода.

🏴‍☠️ @happy_devops

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

В основе партиционирования лежит простая идея — разделить большую таблицу на маленькие части по какому-то признаку. База будет работать с каждой частью как с отдельной таблицей, но для приложения всё останется единым целым. И тут важно не путать партиционирование с шардированием.

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

Партиционирование по времени — самый популярный вариант. Логи, метрики, исторические данные — всё, что имеет временную метку, можно разбить по дням, неделям или месяцам. База будет быстро находить нужный диапазон и не тратить время на сканирование старых данных. А ещё появится возможность по-разному хранить старые и новые данные: свежие держать на SSD, а исторические переносить на медленные диски.

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

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

Из реальной практики: один проект страдал от медленных запросов к логам. Таблица разрослась до нескольких терабайт, индексы не помогали. Разбили данные по дням — и запросы ускорились в десятки раз. Зато другой проект потратил месяц на внедрение партиционирования, а в итоге только усложнил поддержку базы. Потому что не учли: если 90% запросов читают данные из всех партиций, разделение только навредит.

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

🏴‍☠️ @happy_devops

MongoDB, PostgreSQL и Elasticsearch предлагают разные подходы к партиционированию. И дело не только в терминологии — каждая база данных реализует его по-своему, со своими преимуществами и ограничениями.

В PostgreSQL после версии 10.0 появилось декларативное партиционирование. Создаём основную таблицу, указываем стратегию разделения, и база сама распределяет данные по дочерним таблицам. Партиции наследуют структуру родительской таблицы, но могут хранить данные на разных табличных пространствах. Под капотом PostgreSQL использует ограничения и триггеры для маршрутизации данных.

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

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

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

Главный подводный камень во всех базах — запросы, которые работают с несколькими партициями. PostgreSQL приходится объединять данные из разных таблиц, MongoDB собирает результаты со всех затронутых шардов, а Elasticsearch балансирует нагрузку между узлами. Чем больше партиций затрагивает запрос, тем сложнее его выполнить.

И везде есть свои тонкости при работе с индексами. В PostgreSQL индексы создаются отдельно для каждой партиции. MongoDB требует, чтобы ключ шардинга был частью всех уникальных индексов. А в Elasticsearch количество шардов влияет на размер индекса в памяти.

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

🏴‍☠️ @happy_devops

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

Вот реальный кейс из практики. Таблица с данными о транзакциях весила 4 ТБ и росла на 50 ГБ в день. Запросы за последний месяц работали быстро благодаря индексам, но исторические отчеты могли считаться часами. Решение — партиционирование по месяцам.

Первый шаг — создание структуры:

CREATE TABLE transactions_new (
    id bigint,
    created_at timestamp,
    amount decimal,
    -- другие поля
) PARTITION BY RANGE (created_at);

-- Создаем партиции для каждого месяца
CREATE TABLE transactions_2024_01 
PARTITION OF transactions_new 
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

Дальше начинается самое сложное — перенос данных. Прямой INSERT SELECT на таких объемах заблокирует таблицу на часы. Правильный путь — батчинг с параллельной обработкой:

-- Функция для переноса данных за один день
CREATE OR REPLACE FUNCTION migrate_day(day_start date) 
RETURNS integer AS $$
BEGIN
    RETURN WITH moved AS (
        DELETE FROM transactions 
        WHERE created_at >= day_start 
        AND created_at < day_start + interval '1 day'
        RETURNING *
    )
    INSERT INTO transactions_new 
    SELECT * FROM moved;
END;
$$ LANGUAGE plpgsql;

-- Запускаем параллельно для разных дней
SELECT migrate_day(day) 
FROM generate_series('2023-01-01'::date, '2024-01-01', '1 day') day;

Во время миграции критично следить за нагрузкой на диски и CPU. Утилита pg_stat_progress_copy показывает прогресс операций. А автовакуум будет очищать старые версии строк, не давая таблице разрастаться.

Отдельная история — обслуживание партиций. Старые данные можно архивировать, перенося целые партиции на медленные диски:

-- Перемещаем старую партицию на другое табличное пространство
ALTER TABLE transactions_2023_01 
SET TABLESPACE cold_storage;

-- Отключаем автовакуум для старых партиций
ALTER TABLE transactions_2023_01 
SET (autovacuum_enabled = false);

Для автоматизации рутины помогает расширение pg_partman. Оно создает новые партиции заранее и может автоматически архивировать старые:

SELECT partman.create_parent(
    'public.transactions',
    'created_at',
    'range',
    'month',
    p_premake := 3
);

И последнее: партиционирование требует изменений в приложении. Запросы без указания партиционного ключа будут сканировать все партиции. А значит, нужно научить ORM всегда добавлять created_at в условия поиска.

🏴‍☠️ @happy_devops

Репликация данных — основа отказоустойчивости в современных системах. База данных без реплик похожа на сервер без бэкапов: всё работает отлично, пока не случится катастрофа. А потом становится поздно.

Primary-Secondary архитектура — самый распространённый подход. Primary принимает все изменения и пересылает их на реплики. Secondary работают на чтение и готовы подхватить нагрузку при отказе мастера. Звучит просто, но дьявол в деталях.

Синхронная репликация гарантирует, что данные попали на реплику до подтверждения записи. Транзакция не завершится, пока secondary не ответит "данные у меня". Надёжно, но медленно — каждая запись ждёт ответа от реплики. В PostgreSQL это выглядит так:

ALTER SYSTEM SET synchronous_commit TO 'on';
ALTER SYSTEM SET synchronous_standby_names TO 'replica1';

Асинхронная репликация работает в фоне. Primary подтверждает транзакцию сразу, а secondary догоняют когда смогут. Быстро, но есть риск потери данных при падении мастера. MongoDB по умолчанию использует асинхронную репликацию:

{w: 1, j: true} // Ждём запись только на primary
{w: 'majority', j: true} // Ждём запись на большинство нод

Multi-master репликация позволяет писать в любую ноду кластера. Звучит заманчиво, но порождает проблему конфликтов. Две ноды могут одновременно изменить одни и те же данные. Галера-кластер для MySQL решает это через сертификацию транзакций — узлы договариваются о порядке изменений.

Отставание реплик — главная метрика здоровья репликации. В PostgreSQL следим за lag в pg_stat_replication, в MongoDB — за replication lag в rs.status(). Если реплика отстает больше определенного порога — пора разбираться в причинах.

Мониторинг критичен. Нужно следить не только за отставанием, но и за статусом WAL (Write Ahead Log) архивов, свободным местом на дисках реплик и состоянием сетевого соединения между узлами. Один пропущенный WAL сегмент — и придется переинициализировать реплику с нуля.

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

🏴‍☠️ @happy_devops

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

Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут primary-база падает. Автоматический failover звучит заманчиво, но реальность сложнее. В одном проекте автофейловер сработал при кратковременном сетевом сбое, поднял новый primary, а когда связь восстановилась — в системе оказалось два мастера. Итог: split-brain и потерянные транзакции.

Теперь в критичных системах используем ручной failover с Patroni. Конфигурация выглядит так:

scope: postgres-cluster
namespace: /db/
name: postgres1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.0.1:8008

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.0.1:5432
  data_dir: /data/postgres
  bin_dir: /usr/lib/postgresql/14/bin

  parameters:
    max_connections: 100
    shared_buffers: 4GB
    wal_level: replica
    hot_standby: "on"

Каскадная репликация помогает снизить нагрузку на primary. Вместо десяти реплик, висящих на мастере, строим дерево: пара реплик первого уровня раздает WAL остальным. В PostgreSQL это настраивается через primary_conninfo:

-- На реплике первого уровня
primary_conninfo = 'host=10.0.0.1 port=5432'

-- На реплике второго уровня
primary_conninfo = 'host=10.0.0.2 port=5432'

Географически распределенные системы добавляют веселья. Латенция между дата-центрами может достигать сотен миллисекунд. Синхронная репликация в таких условиях убивает производительность. На практике работает схема с локальным кластером в каждом регионе и асинхронной репликацией между регионами.

Мониторинг репликации — отдельное искусство. Следим за метриками через Prometheus:

- job_name: 'postgres_exporter'
  static_configs:
    - targets: ['10.0.0.1:9187']
  metrics_path: /metrics
  params:
    query:
      - 'pg_replication_lag'
      - 'pg_wal_activity'

И обязательно тестируем failover. Регулярно. По графику. С записью времени переключения и подробным разбором каждого случая. Только так можно быть готовым к реальной аварии.

Из последних кейсов: база на 12TB с репликацией между континентами. Переключение на другой континент занимало 40 минут. Ускорили до 5 минут через комбинацию логической и физической репликации: основные таблицы реплицировали физически, а небольшие справочники — логически.

🏴‍☠️ @happy_devops

Версионирование инфраструктуры: практики безопасных изменений 📦

Современная инфраструктура требует продуманного подхода к версионированию. Неконтролируемые изменения в Terraform приводят к простоям сервисов и потере данных. Правильно выстроенное версионирование позволяет избежать этих проблем.

Базовый уровень версионирования — git-тэги для каждого модуля с семантическим версионированием. Мажорная версия растет при несовместимых изменениях, минорная — при добавлении фич, патч — при исправлении ошибок:

module "web_cluster" {
  source = "git::https://github.com/company/tf-modules.git//web-cluster?ref=v2.3.1"
  
  cluster_name = "prod-web"
  instance_count = 5
  zone_id = "Z2FDTNDATAQYW2"
}

История изменений state-файла хранится с помощью версионирования S3. По умолчанию Terraform сохраняет только последнюю версию, поэтому версионирование включается на уровне бакета с правилами очистки старых версий:

resource "aws_s3_bucket" "terraform_state" {
  bucket = "company-terraform-state"

  versioning {
    enabled = true
  }

  lifecycle_rule {
    enabled = true
    noncurrent_version_expiration {
      days = 90
    }
    abort_incomplete_multipart_upload_days = 7
  }
}

Отдельные ветки для каждого окружения с изолированными pipeline'ами позволяют тестировать изменения безопасно. Новые версии модулей проходят проверку в staging перед деплоем в production. При обнаружении проблем revert коммита автоматически возвращает предыдущую версию через CI/CD.

Критичные изменения требуют blue-green deployment. Новая инфраструктура разворачивается параллельно с действующей, трафик переключается постепенно. В случае проблем быстрый откат происходит через DNS:

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "www.example.com"
  type    = "A"

  alias {
    name                   = var.environment == "blue" ? aws_lb.blue.dns_name : aws_lb.green.dns_name
    zone_id                = var.environment == "blue" ? aws_lb.blue.zone_id : aws_lb.green.zone_id
    evaluate_target_health = true
  }
}

🏴‍☠️ @happy_devops

Управление состоянием в Terraform: разделяй и властвуй ⚡️

Состояние инфраструктуры в больших проектах становится узким местом при масштабировании команд и сервисов. Remote state решает проблемы с блокировками и конкурентным доступом, но требует продуманной структуры. Главный принцип — разделение state-файлов по четким границам ответственности.

В основе грамотного управления состоянием лежит принцип разделения state-файлов по логическим границам. Каждый state-файл описывает независимый компонент инфраструктуры. Такой подход уменьшает риск конфликтов при параллельной работе нескольких команд:

# network/main.tf
terraform {
  backend "s3" {
    bucket   = "terraform-states"
    key      = "network/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

# databases/main.tf
terraform {
  backend "s3" {
    bucket   = "terraform-states"
    key      = "databases/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

Для обмена данными между состояниями используется data source terraform_remote_state. Сетевые настройки из одного state становятся доступны другим компонентам. Это позволяет избежать жесткой связанности между модулями и упрощает поддержку кода:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket   = "terraform-states"
    key      = "network/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

resource "yandex_mdb_postgresql_cluster" "postgres" {
  name        = "prod-postgres"
  environment = "PRODUCTION"
  network_id  = data.terraform_remote_state.network.outputs.network_id

  config {
    version = "15"
    resources {
      resource_preset_id = "s3-c2-m8"
      disk_size         = 100
    }
  }
}

При работе с секретами state-файл шифруется на уровне Object Storage через KMS. Ключ доступа выдается только членам инфраструктурной команды. Дополнительный уровень защиты обеспечивает audit log всех операций с state-файлом:

terraform {
  backend "s3" {
    bucket     = "terraform-states"
    key        = "secrets/terraform.tfstate"
    endpoint   = "storage.yandexcloud.net"
    kms_key_id = "abjhq8c9gct5pd5klm7p"
    
    access_key = var.storage_access_key
    secret_key = var.storage_secret_key
  }
}

Отдельное внимание стоит уделить резервному копированию state-файлов. Настройка репликации бакетов между регионами защищает от потери данных при отказе основного региона. А регулярные бэкапы позволяют восстановить состояние на любой момент времени.

🏴‍☠️ @happy_devops