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 50909.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 12937.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 177774.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 39423.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, надеюсь, со временем можно будет работать быстрее и дешевле.
