Я хочу разместить сервер Redis самостоятельно. Я сравнил EC2 с Elasticache. И я хотел бы знать, каков недостаток EC2.
Маленький экземпляр EC2 стоит столько же, сколько крошечный экземпляр ELasticache, но больше 400 мб. Зачем использовать Elasticache и не настраивать собственный Redis Server на ec2 tiny isntance?
Поскольку я ленив, я бы выбрал Elasticcache через EC2, чтобы избежать некоторых из операционных аспектов управления экземпляром Redis. С Redis на EC2 вы отвечаете за масштабирование, обновление, мониторинг и обслуживание хоста и экземпляра Redis. Если вы хорошо разбираетесь в операционных аспектах Redis, тогда это не должно быть проблемой. Многие люди смотрят затраты на операционные аспекты запуска экземпляра Redis. Если вы не будете хорошо приправлены Редисом, я бы подумал об Эластике. Я использовал его и до сих пор очень доволен.
Теперь EC2 имеет смысл, когда вам нужны настраиваемые конфигурации Redis, которые не поддерживаются Elasticache.
Кроме того, ̶ Если вам нужна для подключения к REDIS, например, из за пределами AWS окружающей среды, ̶ ̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶ будет проблема, так как вы не можете используйте REDIS-Cli для подключения к REDIS Instance, который работает в ̶E̶l̶a̶s̶t̶i̶c̶a̶c̶h̶e̶ из ̶o̶u̶t̶s̶i̶d̶e̶.̶
Обновить: Доступ к ресурсам ElastiCache из вне AWS
Наконец, если вы планируете находиться на краю Redis, у вас больше смысла запускать свой собственный. Но опять же, у вас есть операционные биты, мониторинг, исправление и т.д.
tl; dr: Elasticache заставляет вас использовать один экземпляр redis, что является неоптимальным.
Длинная версия:
Я понимаю, что это старый пост (2 года на момент написания этой статьи), но я думаю, что важно отметить, что я не вижу здесь.
На эластике ваше развертывание redis управляется Amazon. Это означает, что вы застряли, но они решили запустить redis.
Redis использует один поток выполнения для чтения/записи. Это обеспечивает согласованность без блокировки. Это главный актив с точки зрения производительности, а не для управления замками и защелками. Несчастливое последствие, тем не менее, заключается в том, что если ваш EC2 имеет более 1 vCPU, они не будут использоваться. Это относится ко всем экземплярам эластичности с более чем одним vCPU.
Размер экземпляра эластичной формы по умолчанию равен cache.r3.large, который имеет два ядра.
Фактически, существует несколько размеров экземпляров с несколькими vCPU. Много возможностей для проявления этой проблемы.
Кажется, Amazon уже знает об этой проблеме, но они, похоже, немного игнорируют ее.
Часть, которая делает это особенно актуальным для этого вопроса, заключается в том, что на вашем EC2 (поскольку вы управляете своим собственным развертыванием) вы можете реализовать multi -tenancy. Это означает, что у вас много экземпляров процесса redis, прослушивающих разные порты. Выбрав порт для чтения/записи в/из приложения на основе хэша ключа записи, вы можете использовать все ваши vCPU.
В качестве побочного примечания; развертывание эластичной резинки redis на многоядерной машине всегда должно выполняться по сравнению с развертыванием эластичных дисков memcached по размеру экземпляра. С многократным арендным договором redis имеет тенденцию быть победителем.
Другим моментом является то, что Elasticache является динамическим, вы можете уменьшить/увеличить память, которую вы используете динамически, или даже закрыть кеш (и сохранить $$), если индексы производительности находятся в зеленом цвете.
t2.micro vs cache.t2.micro
t2.micro - 1GiB cache.t2.micro - 0.555GiB
Но на t2.micro вам нужна ОС!. Большинству из них требуется около 512 мегабайт.
t2.micro может победить, возможно, только в производительности сети. Вы можете попробовать запустить тесты и сравнить.