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

    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, надеюсь, со временем можно будет работать быстрее и дешевле.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 14

      –1
      Большой выбор это не всегда хорошо.
        0
        ИМХО когда много сервисов
        Compute
        Amazon Elastic Compute Cloud (EC2)
        Amazon Elastic MapReduce
        Auto Scaling

        Content Delivery
        Amazon CloudFront

        Database
        Amazon SimpleDB
        Amazon Relational Database Service (RDS)
        Amazon ElastiCache

        Deployment & Management
        AWS Elastic Beanstalk
        AWS CloudFormation

        E-Commerce
        Amazon Fulfillment Web Service (FWS)

        Industry-specific Clouds
        AWS GovCloud (US)

        Messaging
        Amazon Simple Queue Service (SQS)
        Amazon Simple Notification Service (SNS)
        Amazon Simple Email Service (SES)

        Monitoring
        Amazon CloudWatch

        Networking
        Amazon Route 53
        Amazon Virtual Private Cloud (VPC)
        Elastic Load Balancing
        AWS Direct Connect

        Payments & Billing
        Amazon Flexible Payments Service (FPS)
        Amazon DevPay

        Storage
        Amazon Simple Storage Service (S3)
        Amazon Elastic Block Store (EBS)
        AWS Import/Export

        Support
        AWS Premium Support

        Web Traffic
        Alexa Web Information Service
        Alexa Top Sites

        Workforce
        Amazon Mechanical Turk

        Это очень смахивает на выжимание денег.
          +7
          Если мы что-то не используем, это ведь не значит, что это не нужно никому. ;)

          С ElastiCache — интересная идея. Было бы подешевле и сопоставимо с локальным кэшем — я бы пользовался.
          • UFO just landed and posted this here
            0
            Насколько я понимаю это дело хорошо помогает, если у тебя вдруг вылетела нода. То есть пока нода в дауне — данные доступны из кеша. + При использовании этого кеша, наверняка получиться сэкономить их любимые IOS на EBS. Поправьте меня, если я неправ.
              0
              Если ElastiCache использовать как альтернативу кэшу с хранилищем на файловой системе, то, наверное, на IOPS'ах можно сэкономить.

              Если же сравнивать с локальным memcached — вряд ли.
              +4
              мне кажется приведенное тестирование не совсем корректно.

              если сравнивать «с эластик кеш» и «без», то надо:
              — исходить из того, что мы в любом случае используем мемкеш
              — исходить из того, что локальное хранилище нам не подходит
              — в идеале, сэмулировать ситуацию, когда у нас кластер веб-нод, обращающихся к кешу (кластеру кеш-нод)

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

              и тогда сравнить результаты.

              за статью все равно спасибо.
                0
                Да, конечно, такое тестирование было бы гораздо более корректным.

                Но это уже — не для типичного веб-проекта.

                Я же хотел оценить практическую ценность именно для среднего сайта.
                  +1
                  если под средним сайтом подразумевается система с одной аппнодой, то файл-кеш размещенный в tmpfs порвет что угодно.
                  практической ценности для такого «среднего» сайта нет абсолютно ни в чем :)
                +2
                Есть ещё момент: бесплатный трафик между ec2-инстансами и ElastiCache, в отличии от отдельных нод с memcache. Для больших проектов это может быть важно.
                  0
                  Все-таки, не совсем так. Совсем бесплатно — только внутри одной зоны.

                  Внутри региона — платный трафик для EC2:

                  — There is no charge for data transfer between Amazon EC2 and Amazon ElastiCache within the same Availability Zone.
                  — While standard Amazon EC2 Regional Data Transfer charges of $0.01 per GB in/out apply when transferring data between an Amazon EC2 instance and an Amazon ElastiCache Node in different Availability Zones of the same Region, you are only charged for the Data Transfer in or out of the Amazon EC2 instance. There is no Amazon ElastiCache Data Transfer charge for traffic in or out of the Amazon ElastiCache Node itself.

                  0
                  Можно взять vds, установить couchbase и будет ручной «эластичный» memcached-кластер. Или же можно пользоваться облачными сервисами с его поддержкой.
                    0
                    Нужно учесть, что ElastiCache только запущен. Как известно, первый блин комом. Уверен, что в ближайшее время быстродействие взаимодействия с ним ускорится. В первую очередь это в интересах самого Амазона.
                      0
                      Автор, как насчет повторения теста? Скоро уже полгода с момента опубликования материала. Интересно же, какая у них динамика.

                      Only users with full accounts can post comments. Log in, please.