Распределенные системы. Паттерны проектирования - страница 30
к серверу-словарю
Создадим объект ConfigMap , содержащий указанную конфигу-рацию:
kubectl create configmap varnish-config
--from-file=default.vcl
Теперь можно разворачивать реплицированный Varnish-кэш на основе следующего конфигурационного файла: apiVersion: extensions/v1beta1
kind: Deployment
metadata:
94 Часть II. Паттерны проектирования обслуживающих систем name: varnish-cache
spec:
replicas: 2
template:
metadata:
labels:
app: varnish-cache
spec:
containers:
- name: cache
resources:
requests:
# Зарезервируем 2 Гбайт памяти
# для каждого экземпляра Varnish-кэша
memory: 2Gi
image: brendanburns/varnish
command:
- varnishd
- -F
- -f
- /etc/varnish-config/default.vcl
- -a
- 0.0.0.0:8080
- -s
# Количество выделяемой здесь памяти должно
# соответствовать количеству зарезервированной
# памяти, указанному ранее
- malloc,2G
ports:
- containerPort: 8080
volumeMounts:
- name: varnish
mountPath: /etc/varnish-config
volumes:
- name: varnish
configMap:
name: varnish-config
Развернуть реплицированные Varnish-серверы можно следу-ющей командой:
kubectl create -f varnish-deploy.yaml
Глава 5. Реплицированные сервисы с распределением нагрузки 95 Наконец, развернем балансировщик нагрузки для Varnish-кэша: kind: Service
apiVersion: v1
metadata:
name: varnish-service
spec:
selector:
app: varnish-cache
ports:
- protocol: TCP
port: 80
targetPort: 8080
Создать его можно с помощью такой команды: kubectl create -f varnish-service.yaml
Расширение возможностей кэширующей прослойки
Теперь, когда мы развернули кэширующую прослойку для реплицированного stateless-сервиса, посмотрим, что еще он умеет делать, кроме собственно кэширования. Обратные HTTP-прокси вроде Varnish обычно имеют возможность расширения и, помимо кэширования, могут предоставлять дополнительные возможности.
Ограничение частоты запросов и защита от атак типа «отказ в обслуживании» (DoS) Некоторые специалисты проектируют сайты с учетом защиты от DoS-атак. Все больше разработчиков сегодня проектируют программные интерфейсы. В связи с этим отказ в обслужива-нии может произойти из-за того, что разработчик некорректно настроил клиент, либо из-за того, что инженер, ответственный за доступность сайта, случайно запустил нагрузочные тесты 96 Часть II. Паттерны проектирования обслуживающих систем на рабочем сервере. Следовательно, имеет смысл добавить в кэширующую прослойку защиту от отказа в обслуживании, установив ограничение частоты запросов. Большинство об-ратных HTTP-прокси, например Varnish, поддерживают нечто похожее. В частности, у Varnish есть модуль throttle, который можно настроить так, чтобы он ограничивал частоту запросов с определенным путем с конкретных IP-адресов, в том числе для анонимных или зарегистрированных пользователей. Если вы развертываете API, целесообразно иметь достаточно низкий лимит запросов для анонимных пользователей, кото-рый можно повысить после регистрации. Требуя авторизации, мы сможем проводить аудит, чтобы определить, чьи действия привели к неожиданно высокой нагрузке. Ограничение частоты запросов также служит барьером для потенциальных взлом-щиков, которым понадобится замаскироваться под нескольких пользователей, чтобы успешно реализовать атаку. Когда количество запросов от одного пользователя достигает определенного лимита, сервер вернет ему ошибку с кодом 429, означающую превышение количества максимально допустимых запросов. Многим пользователям нужно будет знать, сколько еще они могут сделать запросов, прежде чем достигнут лими-та. В связи с этим вам может понадобиться добавить в HTTP-заголовок информацию о количестве оставшихся запросов. Для подобной информации нет стандартного поля в HTTP-заголовке, однако многие API возвращают одну из разновид-ностей поля X-RateLimit-Remaining .