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

Шардинг (шардирование) — разделение уровня хранилища на несколько независимых частей (шардов), каждая из которых размещается на отдельной машине. В данной главе рассматри-вается одноузловой паттерн проектирования, предназначенный для адаптирования существующих сервисов, чтобы те могли взаимодействовать с другими, шардированными сервисами, находящимися где-то в Интернете. Здесь не рассматривается, откуда появляются шардированные сервисы. О шардировании многоузловом паттерне проектирования шардированных сервисов мы подробно поговорим в главе 6. 52Часть I. Одноузловые паттерны проектирования

Схема шардированного сервиса представлена на рис. 3.2.

Рис. 3.2. Обобщенная схема шардированного сервисаПри развертывании шардированного сервиса возникает вопрос о том, как интегрировать его с программным обеспечением клиентского или промежуточного уровня. Очевидно, должен существовать модуль, который бы переадресовывал конкрет-ный запрос конкретному шарду. Часто такой шардированный клиент тяжело интегрировать в систему, компоненты которой рассчитывают на подключение к единому хранилищу данных. К тому же шардированные сервисы препятствуют совместному использованию конфигурации средой разработки (где храни-лище состоит, как правило, из одного шарда) и средой эксплуа-тации (где хранилище часто состоит из множества шардов). Один из вариантов — включить всю логику шардирования в сам шардированный сервис. При таком подходе шардированный сервис должен также иметь балансировщик нагрузки с незави-симой обработкой транзакций, адресующий трафик нужному шарду. Этот балансировщик нагрузки будет, по сути, распре-Глава 3. Паттерн Ambassador 53

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

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

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

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

Главный результат применения паттерна Ambassador к шар-дированным сервисам — разделение обязанностей между кон-тейнером приложения и шардирующим прокси. Контейнер 54Часть I. Одноузловые паттерны проектирования

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

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

Практикум. Шардируем Redis-хранилище Redis — высокопроизводительное хранилище типа «ключ — значение», которое можно использовать в качестве кэша или более постоянного места хранения данных. В этом примере мы задействуем его в качестве кэша. Начнем с развертывания шардированного Redis на кластер Kubernetes. Для этого об-ратимся к API StatefulSet , поскольку он дает каждому шарду уникальные DNS-имена, которыми мы воспользуемся при на-стройке прокси.

StatefulSet для Redis будет выглядеть следующим образом: apiVersion: apps/v1beta1

kind: StatefulSet

metadata:

name: sharded-redis

spec:

serviceName: "redis"

replicas: 3

template:

metadata:

labels:

app: redis

spec:

Глава 3. Паттерн Ambassador 55

terminationGracePeriodSeconds: 10

containers:

- name: redis

image: redis

ports:

- containerPort: 6379

name: redis

Сохраните этот код в файле redis-shards.yaml , который можно развернуть командой kubectl create -f redis-shards.yaml . Она создаст три контейнера с запущенным Redis. Их можно увидеть, выполнив команду kubectl get pods . Результат будет таким: sharded-redis-[0,1,2]

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

apiVersion: v1

kind: Service

metadata:

name: redis

labels:

app: redis

spec:

ports:

- port: 6379

name: redis

clusterIP: None

selector:

app: redis

Сохраните этот код в файле redis-shards.yaml и разверните полученный файл командой kubectl create -f redis-shards. yaml . Теперь у вас должны появиться DNS-записи для sharded-redis-0.redis , sharded-redis-1.redis и т. д. Воспользуем-ся этими именами для настройки прокси-сервера twemproxy.

56Часть I. Одноузловые паттерны проектирования

Это легковесный, высокопроизводительный прокси-сервер для memcached и Redis, который изначально был разработан в Twitter. Его исходный код теперь доступен на GitHub ( https:// github.com/twitter/twemproxy ).

Следующая конфигурация настроит twemproxy на использова-ние созданных нами копий Redis.

redis:

listen: 127.0.0.1:6379

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

redis: true

timeout: 400

server_retry_timeout: 2000

server_failure_limit: 1

servers:

- sharded-redis-0.redis:6379:1

- sharded-redis-1.redis:6379:1

- sharded-redis-2.redis:6379:1

Из конфигурационного файла видно, что запросы к Redis об-служиваются по адресу localhost:6379 , так что контейнер прило-жения может получить доступ к контейнеру-послу. Его можно развернуть в «посольскую» группу контейнеров, используя Kubernetes-объект ConfigMap , который можно создать такой командой:

kubectl create configmap twem-config --from-file=./nutcracker.yaml Подготовительные мероприятия завершены, и можно развер-нуть наш пример реализации паттерна Ambassador. Определяем группу контейнеров следующим образом: