Б Бёрнс - Распределенные системы. Паттерны проектирования

Кроме того, поскольку каждый шард представляет собой неза-висимый реплицированный сервис, любой шард можно масшта-бировать в зависимости от его текущей нагрузки. Такого рода «горячее» шардирование мы рассмотрим в конце этой главы. Практикум. Развертывание реализации паттерна Ambassador и сервиса memcache для организации шардированного кэша В главе 3 мы рассмотрели процесс развертывания шардирован-ного сервиса Redis. Развертывание шардированного сервиса memcache происходит подобным образом. Сначала развернем memcache с помощью Kubernetes-объекта StatefulSet :

apiVersion: apps/v1beta1

kind: StatefulSet

Глава 6. Шардированные сервисы 109

metadata:

name: sharded-memcache

spec:

serviceName: "memcache"

replicas: 3

template:

metadata:

labels:

app: memcache

spec:

terminationGracePeriodSeconds: 10

containers:

- name: memcache

image: memcached

ports:

- containerPort: 11211

name: memcache

Сохраните этот код в файле с именем memcached-shards.yaml , который можно развернуть командой kubectl create -f mem-cached-shards.yaml . В результате этого будут созданы три кон-тейнера с запущенным сервисом memcached. Как и в примере с Redis, нам также необходимо создать Kubernetes-сервис, который назначит DNS-имена созданным экземплярам memcached. Он будет выглядеть следующим образом: apiVersion: v1

kind: Service

metadata:

name: memcache

labels:

app: memcache

spec:

ports:

- port: 11211

name: memcache

clusterIP: None

selector:

app: memcache

110Часть II. Паттерны проектирования обслуживающих систем Сохраните этот код в файле с именем memcached-service.yaml и разверните полученный файл командой kubectl create -f mem-cached-shards.yaml . Теперь на вашем DNS-сервере должны по-явиться записи для хостов memcache-0.memcache , memcache-1.mem-cache и т. д. Как и в случае с redis, эти имена следует использовать для настройки twemproxy ( https://github.com/twitter/twemproxy ). memcache:

listen: 127.0.0.1:11211

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

timeout: 400

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- memcache-0.memcache:11211:1

- memcache-1.memcache:11211:1

- memcache-2.memcache:11211:1

Из конфигурационного файла видно, что запросы к memcache обслуживаются по адресу localhost:6379 , так что контейнер при-ложения может получить доступ к контейнеру-послу. Теперь можно развернуть его в pod-группу к контейнеру-послу с по-мощью Kubernetes-объекта ConfigMap , который можно создать командой kubectl create configmap --from-file=nutcracker.yaml twem-config .

Подготовительные действия завершены, и теперь вы можете развернуть пример реализации паттерна Ambassador. Определите pod-группу контейнеров, которая выглядит следу-ющим образом:

apiVersion: v1

kind: Pod

metadata:

name: sharded-memcache-ambassador

Глава 6. Шардированные сервисы 111

containers:

# Сюда необходимо подставить имя контейнера приложения, # например:

# - name: nginx

# image: nginx

# Здесь указываем имя контейнера-посла

- name: twemproxy

image: ganomede/twemproxy

command:

- nutcracker

- -c - /etc/config/nutcracker.yaml

- -v - 7

- -s - 6222

volumeMounts:

- name: config-volume

mountPath: /etc/config

volumes:

- name: config-volume

configMap:

name: twem-config

Сохраните этот текст в файл с именем memcached-ambassador-pod.yaml , затем разверните его такой командой: kubectl create -f memcached-ambassador-pod.yaml Если не хотите использовать паттерн Ambassador, можно его не использовать. Вместо этого можно развернуть реплицированный сервис маршрутизации запросов шардам . У паттерна Ambassador, по сравнению с этим сервисом, есть свои достоинства и недостат-ки. Ценность сервиса маршрутизации состоит в снижении слож-ности. Вам не придется разворачивать контейнер-посол в каждой pod-группе, которой нужен доступ к шардированному сервису memcache. Доступ к нему может быть получен с помощью име-нованного сервиса с балансировкой нагрузки. У разделяемого сервиса есть и два недостатка. Во-первых, поскольку сервис используется совместно, его придется масштабировать по мере увеличения нагрузки. Во-вторых, разделяемый сервис — допол-нительный участок пути сетевого маршрута, вносящий лишнюю 112Часть II. Паттерны проектирования обслуживающих систем задержку в обработку запросов и занимающий часть пропускной способности распределенной системы.

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

listen: 0.0.0.0:11211

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

timeout: 400

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- memcache-0.memcache:11211:1

- memcache-1.memcache:11211:1

- memcache-2.memcache:11211:1

Сохраните этот код в файл с именем shared-nutcracker.yaml , затем создайте соответствующий объект ConfigMap с помощью команды kubectl :

kubectl create configmap --from-file=shared-nutcracker.yaml shared-twem-config

Разверните реплицированный сервис маршрутизации запросов шардам:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: shared-twemproxy

spec:

replicas: 3

template:

metadata:

labels:

app: shared-twemproxy

spec:

Глава 6. Шардированные сервисы 113

containers:

- name: twemproxy

image: ganomede/twemproxy

command:

- nutcracker

- -c

- /etc/config/shared-nutcracker.yaml

- -v

- 7

- -s

- 6222

volumeMounts:

- name: config-volume

mountPath: /etc/config

volumes:

- name: config-volume

configMap:

name: shared-twem-config

Сохраните код в файл с именем shared-twemproxy-deploy.yaml , затем разверните реплицированный маршрутизатор запросов шардам с помощью kubectl :

kubectl create -f shared-twemproxy-deploy.yaml Чтобы завершить развертывание маршрутизатора запросов шар-дам, необходимо создать балансировщик нагрузки, обрабатыва-ющий запросы:

kind: Service

apiVersion: v1

metadata:

name: shard-router-service

spec:

selector:

app: shared-twemproxy

ports:

- protocol: TCP

port: 11211

targetPort: 11211

114Часть II. Паттерны проектирования обслуживающих систем Балансировщик нагрузки разворачивается командой kubectl create -f shard-router-service.yaml .

Шардирующие функции

На данный момент мы обсудили процесс проектирования и развертывания просто шардированного и реплицированного шардированного кэша. Настало время уделить внимание тому, каким образом трафик переадресуется тому или иному шарду. Рассмотрим шардированный сервис с десятью независимыми шардами. Дан пользовательский запрос Req . Как выяснить, какой из шардов S с номерами от 0 до 9 должен обработать за-прос? Задача шардирующей функции — определить данное со-ответствие. Шардирующие функции похожи на хеш-функции, с которыми вы наверняка уже сталкивались, например, при из-учении ассоциативных массивов. Действительно, хеш-таблицу в виде массива цепочек можно считать примером шардирован-ного сервиса. Для заданных Req и Shard шардирующая функ-ция должна установить между ними соответствие вида:

Shard = ShardingFunction ( Req ).

Шардирующая функция часто реализуется с использованием хеш-функции и оператора взятия остатка от деления (%). Хеш-функции преобразуют произвольные цепочки байтов в целые числа фиксированной длины . Хеш-функция имеет две важные с точки зрения шардинга характеристики. ‰ ‰ Детерминированность — одинаковые цепочки байтов на

входе должны порождать одинаковый результат на выходе. ‰ ‰ Равномерность — значения хеш-функции должны иметь