Как стать автором
Обновить

Небольшой обзор Amazon ElastiCache — нужен ли он типичному веб-проекту?

Время на прочтение 7 мин
Количество просмотров 6.7K
22 августа Amazon анонсировал новый сервис в AWS — Amazon ElastiCache. На Хабре об этом тоже написали.

Сервис совмести по протоколу с Memcached.

Посмотрим, как он работает и имеет ли практическую ценность для веб-разработчиков и системных администраторов.

Для начала работы необходимо в административном интерфейсе AWS выбрать пункт ElastiCache и указать реквизиты своей банковской карточки, с которой будет осуществляться оплата.

После этого можно переходить собственно к запуску.



Обратите внимание — услуга пока доступна только в одном из пяти регионов, в US East (Virginia).

Ключевое понятие ElastiCache — Cache Cluster.

Внутри кластера можно запускать (вручную или автоматически) нужное количество нод.

Запуская новый кластер, задаем его параметры:



Важные моменты:
  • Node Type — физические характеристики каждой ноды в кластере (RAM, CPU). В одном кластере все ноды обязательно будут одной и той же конфигурации! Варьироваться будет только их количество.
  • Engine — собственно, это не просто совместимость по протоколу с memcached, а это и есть — сам memcached. Возможно, в будущем появятся и какие-то другие варианты.

Дальше задаем Security Group и Cache Parameter Group.

Cache Parameter Group пока (?) единственная и пока (?) не настраивается.

На настройке Security Group хочу остановится немного подробнее.



В настройках группы указывается название Security Group для EC2 — тех виртуальных машин, которые будут иметь доступ к нодам кэш-кластера.

А также AWS Account ID.

Несколько «тонких» моментов:
  • В EC2 Security Group указывается именно название группы, а не идентификатор вида sg-* (как я сам сначала подумал). Если указать какие-то неверные данные, то в большинстве случае даже не будет никакого внятного сообщения об ошибке.

То, что нужно указывать именно название группы, более-менее явно следует только из описания API:

elasticache.us-east-1.amazonaws.com
?Action=AuthorizeCacheSecurityGroupIngress
&EC2SecurityGroupName=default
&CacheSecurityGroupName=mygroup
&EC2SecurityGroupOwnerId=1234-5678-1234
&Version=2011-07-15
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2011-02-12T01%3A29%3A15.746Z
&AWSAccessKeyId=YOUR-ACCESS-KEY
&Signature=YOUR-SIGNATURE


  • Так как все управление файрволлом осуществляется на уровне EC2 Security Group, вы не сможете открыть доступ к Amazon ElastiCache из произвольных сетей. То есть работать с этим сервисом можно только из других сервисов Амазона (в общем случае — EC2).
  • Так как указывается не только EC2 Security Group, но и AWS Account ID, есть возможность дать доступ с другого аккаунта.


В итоге, после того, как все настройки сделаны, запускается нужное количество нод кэш-кластера (я экспериментировал с одной нодой). Для каждой ноды определяется EndPoint — просто пара хост: порт, к которым может обращаться наше приложение.

* * *

Переходим к практическим тестам! :)

Для экспериментов я взял две CMS: самую популярную коммерческую — «1С-Битрикс», и самую популярную open source — Joomla (данные по популярности — из рейтинга iTrack).

Битрикс

Чтобы использовать в качестве хранилища для кэша memcache, можно использовать два варианта:

1. Указать в конфигурационном файле dbconn.php:

define("BX_CACHE_TYPE", "memcache");
define("BX_MEMCACHE_HOST", "testcache.lfffta.0001.use1.cache.amazonaws.com");
define("BX_MEMCACHE_PORT", "11211");


2. Или же (только на старших редакциях «Веб-кластер» и «Бизнес веб-кластер») указать в административном интерфейсе в настройках продукта нужное количество серверов memcached (плюс этого способа в том, что может быть указано любое количество серверов, а не один, что позволяет использовать некий распределенный кэш):



Для тестов на виртуальную машину EC2 (small) установлена демо-версия «1С-Битрикс» 10.0 с типовым контентом из дистрибутива («Интернет-магазин»). Машина развернута в той же AZ (Availability Zone), в которой поднят наш Cache Cluster — чтобы минимизировать влияние сети.

Так как нам не требуется большой детальный тест, а мы хотим лишь оценить скорость работы проекта при использовании Amazon ElastiCache, я не стал использовать полноценные инструменты для нагрузочного тестирования (типа tsung или JMeter), а ограничился простым ab.

Делаем 500 запросов в 2 потока (сразу скажу, что запускал тесты по несколько раз, чтобы получить средние значения).

По методике тестирования у кого-то могут возникнуть замечания. Отмечу еще раз — я сравниваю только две вещи: работу сайтов без использования Amazon ElastiCache и с ним. Абсолютные цифры не интересны, только относительные данные.

# ab -n 500 -c 2 ec2-xx-xx-xx-0.compute-1.amazonaws.com

Первый тест — используем стандартный кэш (диск — файловая система виртуальной машины EC2):

Document Path:          /
Document Length:        25910 bytes

Concurrency Level:      2
Time taken for tests:   53.748 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
	Total transferred:      13324000 bytes
	HTML transferred:       12955000 bytes
	Requests per second:    9.30 [#/sec] (mean)
Time per request:       214.993 [ms] (mean)
Time per request:       107.497 [ms] (mean, across all concurrent requests)
Transfer rate:          242.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0      19
Processing:    51  215 313.9    197    5090
Waiting:       51  215 313.9    196    5090
Total:         51  215 313.9    197    5090


9.3 запросов в секунду

Подключаем ElastiCache и делаем новые тесты:

Concurrency Level:      2
Time taken for tests:   67.987 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      13323973 bytes
HTML transferred:       12954973 bytes
Requests per second:    7.35 [#/sec] (mean)
Time per request:       271.947 [ms] (mean)
Time per request:       135.973 [ms] (mean, across all concurrent requests)
Transfer rate:          191.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   114  272 101.1    279    1293
Waiting:      114  272 101.1    279    1293
Total:        114  272 101.1    279    1293


7.35 запросов в секунду

Медленнее!

Локальный дисковый кэш работает эффективнее, чем memcached, с которым мы «общаемся» по TCP/IP. (Сразу отдельно отмечу, что локально поднятный на той же машине memcached также работает быстрее.)

* * *

Посмотрим на Джумлу

Условия для тестов похожие — на виртуальную машину EC2 (также small, в той же AZ) ставим Joomla 1.7 с типовым демо-контентом.

Запускаем тест — такой же ab:

Concurrency Level:      2
Time taken for tests:   107.028 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      8247000 bytes
HTML transferred:       8068000 bytes
Requests per second:    4.67 [#/sec] (mean)
Time per request:       428.110 [ms] (mean)
Time per request:       214.055 [ms] (mean, across all concurrent requests)
Transfer rate:          75.25 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   159  428 797.5    388   17777
Waiting:      159  428 797.5    388   17777
Total:        159  428 797.5    388   17777


4.67 запросов в секунду

Как-то медленно…

Заходим в админку и видим, что по умолчанию кэширование выключено.

Его можно включить, есть два режима — conservative и progressive.

Используем стандартное хранилище — файловую систему. В первом случае получается 6.6 запросов в секунду, во втором — 7.2:

Concurrency Level:      2
Time taken for tests:   69.440 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      8036000 bytes
HTML transferred:       7857000 bytes
Requests per second:    7.20 [#/sec] (mean)
Time per request:       277.761 [ms] (mean)
Time per request:       138.880 [ms] (mean, across all concurrent requests)
Transfer rate:          113.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.7      0      17
Processing:   123  277  72.3    267     852
Waiting:      123  277  72.4    267     852
Total:        123  277  72.3    267     852


Подключаем для хранилища memcache.

Вообще говоря, по задумке разработчиков Joomla это можно сделать через административный интерфейс.

Однако возможность в принципе использовать memcache проверяется вот таким вот кодом:

public static function test()
{
if ((extension_loaded('memcache') && class_exists('Memcache')) != true ) {
return false;
}

$config = JFactory::getConfig();
$host = $config->get('memcache_server_host', 'localhost');
$port = $config->get('memcache_server_port', 11211);

$memcache = new Memcache;
$memcachetest = @$memcache->connect($host, $port);

if (!$memcachetest) {
return false;
} else {
return true;
}
}


Если функция test вернет false, то в меню для выбора хранилища memcache не будет в принципе.

То есть для первичного указания параметров соединения нам нужно либо в явном виде прописать параметры в конфигурационном файле configuration.php, либо запустить «дефолтный» memcached (localhost:11211).

Указываем в configuration.php:

public $memcache_persist = '1';
public $memcache_compress = '0';
public $memcache_server_host = 'testcache.lfffta.0001.use1.cache.amazonaws.com';
public $memcache_server_port = '11211';


Тестируем:

Concurrency Level:      2
Time taken for tests:   140.928 seconds
Complete requests:      500
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Non-2xx responses:      3
Total transferred:      8002436 bytes
HTML transferred:       7823370 bytes
Requests per second:    3.55 [#/sec] (mean)
Time per request:       563.712 [ms] (mean)
Time per request:       281.856 [ms] (mean, across all concurrent requests)
Transfer rate:          55.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   142  563 397.1    461    3942
Waiting:      142  563 397.1    460    3942
Total:        142  564 397.1    461    3942


3.55 запросов

Ожидаемо — медленнее. :(

Но неожиданно — даже медленнее, чем вообще без использования кэша. :(

Сразу скажу, что в итоге попробовал взять для тестов другой Cache Cluster, с более мощными нодами кэша. Получил лишний небольшой прирост производительности по сравнению с «тестовым образцом».

* * *

Резюмируем

Если коротко — для средних проектов (которых большинство) Amazon ElastiCache на данный момент не имеет особого смысла… :(
  • Конфигурирование — сопоставимо (если не сложнее) с настройкой локального memcached на том же (или на другом) инстансе.
  • Цена — сопоставима с EC2 (small ElastiCache 1.3 Гб — $0.095 в час, small EC2 1.7 Гб — $0.085 в час).
  • Можно использовать только с другими сервисами AWS.
  • Отдельные EndPoint для каждой ноды (а не для всего Cache Cluster в целом) позволяют использовать возможности масштабирования и т.п. только в тех продуктах, в которых можно подключить больше одного сервера memcached (как, например, в том же веб-кластере «1С-Битрикс»).

В каких случаях можно, нужно и полезно использовать ElastiCache:
  • На больших проектах, где требуется огромный (и — важно — масштабируемый как в сторону увеличения, так и в сторону уменьшения) кэш. ElastiCache позволяет использовать очень большое количество различных метрик в CloudWatch (от количества переданных данных и хитов до CPU Utilization и количества используемой/неиспользуемой памяти), по которым можно задавать те или иные правила для автоматического масштабирования.
  • В тех проектах, где критически важна доступность кэш-серверов (ElastiCache мониторит состояние нод кэш-кластера и автоматически их восстанавливает в случае каких-либо проблем).

Вообще говоря, конечно, Amazon движется в правильном направлении, предоставляя все больше «облачных» сервисов. Чем больше выбор у пользователя — тем лучше.

Ну, а с ElastiCache, надеюсь, со временем можно будет работать быстрее и дешевле.
Теги:
Хабы:
+37
Комментарии 14
Комментарии Комментарии 14

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн