autccaling memcache и elasticache

Question

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

Имеет ли AWS Elasticache с автоматическим обнаружением какие-либо умственные способности, чтобы остановить это, поскольку он поддерживает добавление узлов и подключается через один IP-адрес? Насколько я вижу, ответ отрицательный, поскольку он существенно изменяет конфигурацию динамически на основе списка серверов в записи обнаружения и, таким образом, будет страдать от той же проблемы, но, надеюсь, кто-то, кто знает больше меня, может сказать в любом случае.

На заднем плане я смотрю AWS Opsworks и задаюсь вопросом, следует ли использовать Elasticache или memcached-слой.

Answer 1

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

Теперь на ваш вопрос ...

ли не автоматическое масштабирование «хорошая идея» может зависеть частично от того, может ли или не ваше приложение потерпит ключ переназначения.

И независимо от того, переназначаются ли ваши ключи при изменении кластера, зависит от того, как вы используете ваш клиент memcached, а не только от службы AWS Elasticache.

Для memcached клиентских библиотек, которые я видел, я считаю, что предположение верно. Если вы добавите или удалите узлы из кластера, и вы используете клиент Auto Discovery, ключи будут переназначены.

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

1. Не использовать автоматическое обнаружение. Вместо этого настройте своего клиента, чтобы всегда использовать максимальное количество узлов - независимо от того, сколько из них работает. Имена узлов в кластере emacache memcached предсказуемы. Например, если ваша стратегия автоматического масштабирования позволит использовать максимум 5 узлов, но вы обычно работаете с 2, продолжайте и сообщите клиенту вашего кеша, что узлы: mc.xxxxxx.0001.use1.cache.amazonaws.com, mc .xxxxxx.0002.use1.cache.amazonaws.com, mc.xxxxxx.0003.use1.cache.amazonaws.com, mc.xxxxxx.0004.use1.cache.amazonaws.com, mc.xxxxxx.0005.use1.cache .amazonaws.com
2. Использовать клиент, который поддерживает алгоритм определения местоположения узла, который минимизирует переопределение ключей, например Ketama Node Locater, разработанное last.fm для решения этой проблемы.

Downsides этого подхода являются: 1. Во время нормального времени работы, ваш клиент кэш постоянно выполняет проверку мертвых узлов для узлов, которые не существуют. 2. После события масштабирования узлы, используемые в вашей обычной конфигурации запуска, по-прежнему будут содержать большинство ключей, если вы не сделаете немного больше работы. Например, вы можете использовать осколок и основывать количество осколков на количестве текущих узлов.

Это начинает усложняться.

То, что я сделал на практике вместо этого, это ручное масштабирование Elasticache и планирование событий масштабирования, возникающих во время непикового трафика.