Готовим высокодоступный memcached с mcrouter в Kubernetes

В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.

Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…

Проблема

После миграции в K8s проект выиграл в целом за счет легкости масштабирования и прозрачности работы выбранной схемы с кэшированием. Однако средняя отзывчивость приложения снизилась. Анализ производительности средствами New Relic показал, что после переезда заметно выросло время, которое приложение стало проводить в memcached.

Я стал изучать причину возросших задержек и понял, что они связаны исключительно с сетевой конфигурацией. Если раньше приложение и memcached находились на одном физическом узле, то в K8s-кластере Pod с приложением и Pod с memcached чаще всего оказывались на разных узлах. В таких случаях неизбежны сетевые задержки.

Решение

NB. Предложенная ниже методика проверена в production-кластере с 10 экземплярами memcached. На более масштабных инсталляциях решение не проверялось.

Очевидно, что memcached необходимо запускать в DaemonSet на тех же узлах, на которых работает приложение, а значит — потребуется настройка node affinity. Чтобы конфигурация была интересной, прикладываю приближенный к production листинг, в котором можно также увидеть probes и requests/limits:

apiVersion: apps/v1 kind: DaemonSet metadata:  name: mc  labels:    app: mc spec:  selector:    matchLabels:      app: mc  template:    metadata:      labels:        app: mc    spec:      affinity:        nodeAffinity:          requiredDuringSchedulingIgnoredDuringExecution:            nodeSelectorTerms:            - matchExpressions:              - key: node-role.kubernetes.io/node                operator: Exists      containers:      - name: memcached        image: memcached:1.6.9        command:        - /bin/bash        - -c        - --        - memcached --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache        ports:        - name: mc-production          containerPort: 30213        livenessProbe:          tcpSocket:            port: mc-production          initialDelaySeconds: 30          timeoutSeconds: 5        readinessProbe:          tcpSocket:            port: mc-production          initialDelaySeconds: 5          timeoutSeconds: 1        resources:          requests:            cpu: 100m            memory: 2560Mi          limits:            memory: 2560Mi --- apiVersion: v1 kind: Service metadata:  name: mc spec:  selector:    app: mc  clusterIP: None  publishNotReadyAddresses: true  ports:  - name: mc-production    port: 30213

Но у приложения есть дополнительное требование к когерентности кэша. Данные во всех экземплярах кэша должны точно соответствовать данным в реляционной БД. В приложении есть механизм, который в обязательном порядке при обновлении в БД кэшируемых данных также обновляет их и в memcached. Следовательно, нам необходимо обеспечить механизм, который транслировал бы обновления кэша, произведенные экземпляром приложения на одном из узлов, на все остальные узлы. Для этого в качестве прослойки между приложением и memcached прекрасно подходит mcrouter — маршрутизатор для масштабирования memcached-инсталляций. Мы уже даже писали о нем статью.

Добавляем в кластер mcrouter

Чтобы ускорить чтение данных из кэша, mcrouter тоже нужно запустить как DaemonSet. Так mcrouter будет «знать», какой из экземпляров memcached — ближайший, т. е. запущен на его узле. Для этого mcrouter можно поместить sidecar-контейнером в Pod’ы с memcached. Тогда ближайший memcached для mcrouter’a будет находиться по адресу 127.0.0.1.

Но чтобы повысить отказоустойчивость, лучше выделить mcrouter в отдельный DaemonSet и вынести memcached и mcrouter в hostNetwork. При таком разделении любые проблемы с каким-либо экземпляром memcached не повлияют на доступность кэша для приложения. Перевыкат как для memcached, так и для mcrouter можно выполнять раздельно, что повышает отказоустойчивость всей системы при таких операциях.

Чтобы выделить memcached в hostNetwork, добавим в манифест: hostNetwork: true.

 Также добавим переменную окружения с IP-адресом узла, на котором запущен Pod, в контейнер с memcached:

       env:        - name: HOST_IP          valueFrom:            fieldRef:              fieldPath: status.hostIP

И модифицируем команду запуска memcached, чтобы порт был открыт только на внутреннем IP кластера:

       command:        - /bin/bash        - -c        - --        - memcached --listen=$HOST_IP --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache

Аналогично опишем DaemonSet mcrouter’a, Pod’ы которого также должны запускаться в hostNetwork:

apiVersion: apps/v1 kind: DaemonSet metadata:  name: mcrouter  labels:    app: mcrouter spec:  selector:    matchLabels:      app: mcrouter  template:    metadata:      labels:        app: mcrouter    spec:      affinity:        nodeAffinity:          requiredDuringSchedulingIgnoredDuringExecution:            nodeSelectorTerms:            - matchExpressions:              - key: node-role.kubernetes.io/node                operator: Exists      hostNetwork: true      imagePullSecrets:      - name: "registrysecret"      containers:      - name: mcrouter        image: {{ .Values.werf.image.mcrouter }}        command:        - /bin/bash        - -c        - --        - mcrouter --listen-addresses=$HOST_IP --port=31213 --config-file=/mnt/config/config.json --stats-root=/mnt/config/        volumeMounts:        - name: config          mountPath: /mnt/config        ports:        - name: mcr-production          containerPort: 30213        livenessProbe:          tcpSocket:            port: mcr-production          initialDelaySeconds: 30          timeoutSeconds: 5        readinessProbe:          tcpSocket:            port: mcr-production          initialDelaySeconds: 5          timeoutSeconds: 1        resources:          requests:            cpu: 300m            memory: 100Mi          limits:            memory: 100Mi        env:        - name: HOST_IP          valueFrom:            fieldRef:              fieldPath: status.hostIP      volumes:      - configMap:          name: mcrouter        name: mcrouter      - name: config        emptyDir: {}

Поскольку mcrouter тоже запущен в hostNetwork, для него также сделано ограничение, чтобы порт открывался только на внутреннем IP узлов.

Вариант сборки mcrouter, как мы это делаем с помощью werf (не составит труда переписать на обычный Dockerfile, если такая необходимость есть):

image: mcrouter from: ubuntu:18.04 mount: - from: tmp_dir  to: /var/lib/apt/lists ansible: beforeInstall: - name: Install prerequisites   apt:     name:     - apt-transport-https     - apt-utils     - dnsutils     - gnupg     - tzdata     - locales     update_cache: yes - name: Add mcrouter APT key   apt_key:     url: https://facebook.github.io/mcrouter/debrepo/bionic/PUBLIC.KEY - name: Add mcrouter Repo   apt_repository:     repo: deb https://facebook.github.io/mcrouter/debrepo/bionic bionic contrib     filename: mcrouter     update_cache: yes - name: Set timezone   timezone:     name: "Europe/Moscow" - name: Ensure a locale exists   locale_gen:     name: en_US.UTF-8     state: present install: - name: Install mcrouter   apt:     name:     - mcrouter

И самое интересное — это конфигурационный файл mcrouter. Он должен генерироваться на лету, при запуске Pod’а на конкретном узле, чтобы подставить адрес «своего» узла как приоритетный для чтения. Для этого необходим init-контейнер в Pod’е с mcrouter’ом, который генерирует конфигурационный файл и подкладывает его в общий volume в emptyDir:

     initContainers:      - name: init        image: {{ .Values.werf.image.mcrouter }}        command:        - /bin/bash        - -c        - /mnt/config/config_generator.sh /mnt/config/config.json        volumeMounts:        - name: mcrouter          mountPath: /mnt/config/config_generator.sh          subPath: config_generator.sh        - name: config          mountPath: /mnt/config        env:        - name: HOST_IP          valueFrom:            fieldRef:              fieldPath: status.hostIP

Вот так может выглядеть сам генератор конфигурационного файла, который выполняется в init-контейнере:

apiVersion: v1 kind: ConfigMap metadata:  name: mcrouter data:  config_generator.sh: |    #!/bin/bash    set -e    set -o pipefail      config_path=$1;    if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi      function join_by { local d=$1; shift; local f=$1; shift; printf %s "$f" "${@/#/$d}"; }      mapfile -t ips < <( host mc.production.svc.cluster.local 10.222.0.10 | grep mc.production.svc.cluster.local | awk '{ print $4; }' | sort | grep -v $HOST_IP )      delimiter=':30213","'      servers='"'$(join_by $delimiter $HOST_IP "${ips[@]}")':30213"'      cat <<< '{      "pools": {        "A": {          "servers": [            '$servers'          ]        }      },      "route": {        "type": "OperationSelectorRoute",        "operation_policies": {          "add": "AllSyncRoute|Pool|A",          "delete": "AllSyncRoute|Pool|A",          "get": "FailoverRoute|Pool|A",          "set": "AllSyncRoute|Pool|A"        }      }    }    ' > $config_path

Скрипт обращается к внутреннему DNS в K8s-кластере, получает все IP-адреса для Pod’ов memcached и формирует список адресов. Первый в списке — IP-адрес того узла, на котором запущен наш экземпляр mcrouter.

Обратите внимание! Для того, чтобы при обращении к DNS были получены адреса Pod’ов, в приведенном выше манифесте Service для memcached указана спецификация clusterIP: None.

Результат работы скрипта:

cat /mnt/config/config.json {   "pools": {     "A": {       "servers": [ "192.168.100.33:30213","192.168.100.14:30213","192.168.100.15:30213","192.168.100.16:30213","192.168.100.21:30213","192.168.100.22:30213","192.168.100.23:30213","192.168.100.34:30213"       ]     }   },   "route": {     "type": "OperationSelectorRoute",     "operation_policies": {       "add": "AllSyncRoute|Pool|A",       "delete": "AllSyncRoute|Pool|A",       "get": "FailoverRoute|Pool|A",       "set": "AllSyncRoute|Pool|A"     }   } }

Так мы обеспечиваем синхронизацию записи изменений на все экземпляры memcached и приоритетное чтение со «своего» узла.

NB. Если строгого требования к когерентности кэша нет, то для большей скорости работы и меньшей чувствительности к нестабильности кластера в целом рекомендуется вместо AllSyncRoute использовать дескриптор маршрута AllMajorityRoute или даже AllFastestRoute.

Поправка на ветер

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

• Появятся новые экземпляры memcached и mcrouter.

• Новые экземпляры mcrouter будут писать в старые экземпляры memcached. А старые экземпляры mcrouter о новых экземплярах memcached не узнают.

А в случае уменьшения числа узлов — при условии использовании в mcrouter политики AllSyncRoute — кэш на узлах фактически перейдет в режим read-only.

Вариант решения: в Pod’е с mcrouter’ом сделать sidecar-контейнер с cron’ом, по которому бы делалась проверка списка узлов и применялись изменения.

Конфигурация sidecar’а:

     - name: cron        image: {{ .Values.werf.image.cron }}        command:        - /usr/local/bin/dumb-init        - /bin/sh        - -c        - /usr/local/bin/supercronic -json /app/crontab        volumeMounts:        - name: mcrouter          mountPath: /mnt/config/config_generator.sh          subPath: config_generator.sh        - name: mcrouter          mountPath: /mnt/config/check_nodes.sh          subPath: check_nodes.sh        - name: mcrouter          mountPath: /app/crontab          subPath: crontab        - name: config          mountPath: /mnt/config        resources:          limits:            memory: 64Mi          requests:            memory: 64Mi            cpu: 5m        env:        - name: HOST_IP          valueFrom:            fieldRef:              fieldPath: status.hostIP

Скрипты, работающие в этом cron’е, вызывают тот же самый config_generator.sh, который используется в init-контейнере:

 crontab: |    # Check nodes in cluster    * * * * * * *   /mnt/config/check_nodes.sh /mnt/config/config.json    check_nodes.sh: |    #!/usr/bin/env bash    set -e      config_path=$1;    if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi      check_path="${config_path}.check"      checksum1=$(md5sum $config_path | awk '{print $1;}')      /mnt/config/config_generator.sh $check_path      checksum2=$(md5sum $check_path | awk '{print $1;}')      if [[ $checksum1 == $checksum2 ]]; then        echo "No changes for nodes."        exit 0;    else        echo "Node list was changed."        mv $check_path $config_path        echo "mcrouter is reconfigured."    fi

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

Теперь осталось только в Pod’е с приложением указать IP-адрес самого узла — в переменной окружения, в которой указывается адрес memcached. А в качестве порта memcached указать порт mcrouter’a:

       env:        - name: MEMCACHED_HOST          valueFrom:            fieldRef:              fieldPath: status.hostIP        - name: MEMCACHED_PORT          value: 31213

Результат

В итоге цель проекта была достигнута: удалось заметно ускорить работу приложения. По данным New Relic, время взаимодействия приложения с memcached в процессе обработки пользовательского запроса сократилось с 70-80 мс до ~20 мс.

Состояние до оптимизации:

После оптимизации:

Решение применяется в production примерно полгода, и за это время подводных камней не всплыло.

Итоговые листинги, упомянутые в статье (Helm-чарты и werf.yaml), доступны в репозитории flant/examples.

P.S.

Читайте также в нашем блоге:

• «Используем mcrouter для горизонтального масштабирования memcached»;

• «KeyDB как [потенциальная] замена Redis»;

• «Беспростойная миграция RabbitMQ в Kubernetes».