Вопросы и ответы по Amazon ElastiCache

Бессерверная конфигурация ElastiCache – это вариант сервиса, позволяющий начать работу с кэшем менее чем за минуту без выделения инфраструктуры или планирования ресурсов. Бессерверная конфигурация ElastiCache устраняет необходимость в трудоемком планировании ресурсов благодаря постоянному мониторингу использования вычислительных ресурсов, памяти и сети кэша, что позволяет мгновенно масштабировать кэш в соответствии с потребностями без простоев и снижения производительности. Бессерверная конфигурация ElastiCache автоматически реплицирует данные в нескольких зонах доступности и предоставляет клиентам SLA с коэффициентом 99,99 % для каждого кэша. При использовании бессерверной конфигурации ElastiCache вы платите только за хранимые данные и вычислительные ресурсы, применяемые вашим приложением. Чтобы начать, создайте кэш бессерверной конфигурации ElastiCache всего за несколько шагов, присвоив ему имя с помощью консоли, пакета средств разработки ElastiCache (SDK) или интерфейса командной строки AWS (AWS CLI).

Можно перенести существующую рабочую нагрузку ElastiCache, изменив адрес Valkey, Memcached или Redis OSS на новый адрес кэша бессерверной конфигурации ElastiCache в приложении. Указав местоположение файла резервной копии в Простом сервисе хранения данных Amazon Simple Storage Service (Amazon S3), можно перенести существующие данные Elasticache в бессерверную конфигурацию Elasticache. Ознакомьтесь с документацией о бессерверной конфигурации Elasticache, чтобы узнать больше о переносе рабочих нагрузок.

Бессерверная конфигурация ElastiCache поддерживает Valkey 7.2, Memcached версии 1.6.21, а также OSS Redis версии 7.0 и более новых версий.

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

Бессерверная конфигурация ElastiCache автоматически сохраняет данные во многих зонах доступности для обеспечения избыточности и для нее соглашение об уровне обслуживания гарантирует доступность на уровне 99,99 % для всех рабочих нагрузок.

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

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

Благодаря зарезервированным узлам можно получить скидку на использование ElastiCache по запросу. Бессерверная конфигурация ElastiCache несовместима с зарезервированными узлами.

Сервис позволяет приобрести до 300 зарезервированных узлов. Если требуется запустить более 300 узлов, заполните форму запроса узлов ElastiCache.

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

Изменение тарифов, связанное с зарезервированным узлом, произойдет сразу после получения запроса и обработки платежа. За состоянием зарезервированных узлов кэша можно следить на странице AWS «История аккаунта» или с помощью API DescribeReservedCacheNodes. Если разовый платеж не удастся успешно выполнить к началу следующего расчетного периода, тариф со скидкой применен не будет.

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

API ElastiCache для создания, изменения и удаления узлов являются одинаковыми как для узлов по требованию, так и для зарезервированных узлов, поэтому их можно просто использовать в обоих случаях. При составлении счета наша система автоматически применит тарифы зарезервированных узлов, чтобы соответствующие узлы оплачивались по более низкому почасовому тарифу.

Каждый зарезервированный узел связан с определенным регионом. Эта связь сохраняется в течение всего срока резервирования, поэтому ее нельзя изменить. Однако каждое резервирование может использоваться в любой зоне доступности в пределах соответствующего региона.

Нет. Отменить резервирование узла нельзя, и внесенный разовый платеж (если таковой взимался) не возвращается. Каждый час в течение срока действия зарезервированных узлов подлежит оплате независимо от использования.

Если зарезервированный узел приобретается с полной предоплатой, его стоимость будет целиком оплачена авансовым платежом. При выборе варианта «Без предоплаты» авансовые платежи не потребуются. Общая стоимость зарезервированного узла без авансового платежа будет распределена по выплатам за каждый час (вне зависимости от использования инстанса). Частичная предоплата сочетает в себе свойства планов без авансового платежа и вариантов с полной предоплатой. При данном сценарии потребуется небольшой авансовый платеж, а затем при каждой почасовой выплате будет дополнительно взиматься небольшая сумма (вне зависимости от использования инстанса).

Да, зарезервированные узлы ElastiCache предлагают гибкость размера в пределах того же семейства инстансов (или семейства узлов) и в том же регионе AWS. Это означает, что скидка на зарезервированные узлы будет автоматически применяться к использованию узлов всех размеров из выбранного семейства.

ElastiCache позволяет настроить шифрование данных в местах хранения с помощью Сервиса управления ключами AWS (AWS KMS), шифрование данных в движении посредством протокола TLS (безопасность транспортного уровня), аутентификацию благодаря Управлению идентификацией и доступом AWS (IAM) и контроль доступа к сети с использованием групп безопасности Эластичного облака вычислений Amazon (Amazon EC2).

Если вы не используете Amazon Virtual Private Cloud (Amazon VPC), ElastiCache позволяет контролировать доступ к кэшу посредством групп безопасности сети. Группа безопасности работает как брандмауэр, управляя сетевым доступом к кэшам. По умолчанию сетевой доступ к кэшам запрещен. Если вы хотите, чтобы приложения имели доступ к кэшу, вы должны явно разрешить доступ для соответствующих узлов в конкретных группах безопасности Amazon EC2.

Вы также можете контролировать доступ к ресурсам ElastiCache с помощью аутентификации IAM. Дополнительные сведения см. в документации об аутентификации с помощью IAM.

ElastiCache поддерживает такие программы соответствия требованиям, как SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA и FedRAMP. Актуальный перечень поддерживаемых программ соответствия требованиям см. на странице Сервисы AWS в программе обеспечения соответствия требованиям.

Да. ElastiCache входит в программу соответствия AWS требованиям PCI. Ресурсы с подробной информацией см. ниже.

• Нормативно-правовое соответствие Elasticache
• Страница соответствия AWS требованиям PCI

Актуальный перечень программ соответствия, распространяющихся на ElastiCache, см. на странице Сервисы AWS в программе обеспечения соответствия требованиям.

Да. ElastiCache соответствует требованиям HIPAA и подпадает под действие договора делового партнерства AWS (BAA). Это означает, что ElastiCache можно использовать для обработки, обслуживания и хранения закрытой медицинской информации (PHI) и применять в приложениях для сферы здравоохранения.

Нет, дополнительная плата за использование возможностей соответствия требованиям не взимается.

Если договор BAA с AWS уже заключен, можно сразу использовать ElastiCache для создания приложений, хранящих и обрабатывающих PHI в соответствии с HIPAA. Если договора BAA нет или имеются другие вопросы об использовании AWS для приложений, свяжитесь с нами для получения дополнительной информации. 

Elasticache входит в программу соответствия AWS требованиям FedRAMP в качестве авторизованного сервиса. С помощью последней версии сервиса Elasticache клиенты и партнеры правительства США могут обрабатывать и хранить данные и системы, соответствующие требованиям FedRAMP, а также размещать критически важные рабочие процессы с высоким уровнем риска в регионе AWS GovCloud (США – восток) и AWS GovCloud (США – запад), а процессы со средним уровнем риска – в регионах «Восток США (Огайо)», «Восток США (Северная Вирджиния)», «Запад США (Северная Калифорния)» и «Запад США (Орегон)».

Ресурсы с подробной информацией см. ниже.

• Нормативно-правовое соответствие Elasticache
• Нормативно-правовое соответствие AWS FedRAMP

Актуальный перечень программ соответствия, распространяющихся на ElastiCache, см. на странице Сервисы AWS в программе обеспечения соответствия требованиям.

Таких преимуществ несколько.

Elasticache предоставляет улучшенные потоки ввода-вывода, которые значительно повышают пропускную способность и сокращают задержки при масштабировании за счет мультиплексирования, разгрузки уровня представления и многого другого. Усовершенствованные потоки ввода-вывода повышают производительность за счет использования большего количества ядер для обработки операций и динамической адаптации к рабочей нагрузке. Elasticache повышает пропускную способность кластеров с поддержкой протокола TLS за счет переноса шифрования на те же усовершенствованные потоки ввода-вывода. Это позволяет ElastiCache для Valkey обеспечить увеличение пропускной способности до 100 % и снижение задержки P99 на 50 % по сравнению с версией ElastiCache 7.0 для Redis OSS. На узлах r7g.4xlarge или более больших можно обрабатывать свыше 1 млн запросов в секунду на узел или 500 млн запросов в секунду на кластер.

Кроме того, версия ElastiCache 8.0 для Valkey позволяет повысить эффективность использования памяти для кластеров на основе узлов в кластерном режиме за счет использования на 32 байта меньше памяти на раздел по сравнению с версией ElastiCache 7.2 для Valkey и версией 7.1 для Redis OSS. Бессерверная конфигурация обеспечивает повышенную производительность благодаря масштабированию до 5 миллионов запросов в секунду на кэш за считаные минуты, что в 5 раз быстрее, чем у Valkey 7.2, при этом задержка чтения составляет несколько микросекунд.

Elasticache предоставляет два разных набора метрик для измерения использования ЦП кэша в зависимости от выбранного варианта развертывания кэша. При использовании бессерверной конфигурации ElastiCache можно отслеживать загрузку ЦП с помощью метрики ElastiCache Processing Units (ECPU). Количество ECPU, используемых вашими запросами, зависит от времени, затраченного виртуальным ЦПУ, и объема переданных данных. Для каждого простого чтения и записи, например команд Valkey GET и SET или команд Memcached get и set, требуется 1 ECPU на каждый переданный килобайт (КБ) данных. Некоторые команды, работающие со структурами данных в памяти, могут дольше использовать виртуальный процессор, чем команды GET или SET. ElastiCache вычисляет количество использованных ECPU на основе времени, затраченного на выполнение команды виртуальным процессором, по сравнению с базовым показателем времени его работы, затрачиваемого командой SET или GET. Если выполнение команды занимает дополнительное время использования виртуального процессора и передает больше данных, чем 1 ECPU при базовой производительности, Elasticache рассчитывает необходимое количество процессоров на основе большего из двух параметров.

При проектировании собственного кластера вы можете отслеживать метрики EngineCPUUtilization и CPUUtilization. Метрика CPUUtilization оценивает загрузку ЦП для каждого инстанса (узла), а EngineCPUUtilization – общую загрузку ЦП на уровне процесса ядра. Метрика EngineCPUUtilization введена в дополнение к метрике CPUUtilization, так как основной процесс ядра является однопоточным и использует только одно ядро из всех доступных на инстансе ядер ЦП. Соответственно, метрика CPUUtilization не отражает в полной мере степень загрузки ЦП на уровне процесса. Чтобы точно понимать фактическую загрузку ЦП на кластерах Valkey, рекомендуется использовать сочетание метрик CPUUtilization и EngineCPUUtilization.

Оба набора метрик доступны во всех регионах AWS, а работать с ними можно с помощью сервиса Amazon CloudWatch или консоли. Кроме того, мы рекомендуем ознакомиться с документацией, чтобы узнать о полезных метриках для мониторинга производительности.

Реплики чтения служат для двух целей:

• обработки сбоев;
• масштабирования при обслуживании запросов чтения.

При запуске кэша как реплики чтения первичный узел обслуживает процессы записи и чтения. Реплика обслуживает исключительно трафик чтения, а также доступна в среде теплого резервирования на случай повреждения первичного узла.

В бессерверной конфигурации Elasticache реплики чтения автоматически поддерживаются сервисом. При проектировании собственного кэша развертывание одной и более реплик чтения для данного первичного узла успешно применяется в различных сценариях. Ниже перечислены самые распространенные из них.

• Масштабирование вычислительных ресурсов или ресурсов ввода‑вывода одного первичного узла для выполнения рабочих нагрузок с большим количеством операций чтения. Избыточный трафик чтения можно направить на одну и более реплик чтения.
• Обслуживание трафика чтения в случае недоступности первичного узла. Если первичный узел не принимает запросы ввода‑вывода (например, в связи с приостановкой ввода‑вывода во время выполнения резервного копирования или запланированного обслуживания), трафик операций чтения можно направить на реплики чтения. Следует учесть, что в этом случае данные, которые содержит реплика чтения, могут оказаться устаревшими вследствие недоступности основного инстанса. Реплику чтения также можно использовать для перезапуска отказавшего первичного узла.

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

Вы можете подключиться к реплике чтения так же, как и к первичному узлу кэша. Порядок распределения трафика чтения по множеству реплик чтения определяется приложением. Дополнительные сведения.

• Кластеры Valkey или OSS Redis (режим кластера отключен) используют отдельные адреса узла для операций чтения (в API и CLI они называются адресами чтения).
• Кластеры Valkey или OSS Redis (режим кластера включен) используют для всех адресов конфигурации кластера. Кроме того, выполнять операции чтения по-прежнему можно из адресов узлов (в API и CLI они называются адресами чтения).

ElastiCache позволяет создать не более пяти (5) реплик чтения для одного первичного узла кэша.

В случае аварийного переброса репликация всех связанных и доступных реплик чтения автоматически возобновится сразу же по завершении переброса (с применением обновлений, которые содержатся в репликах, ставших основными).

Обновления первичного узла кэша автоматически реплицируются во все связанные реплики чтения. Однако в связи с применением поддерживаемой Valkey или OSS Redis асинхронной репликации обновления реплики чтения могут отставать от обновлений соответствующего первичного узла кэша. Ниже перечислены наиболее частые причины такого отставания.

• Объем операций ввода‑вывода при записи в первичный узел кэша превышает скорость применения обновлений к реплике чтения.
• Сетевое разграничение или задержка между первичным узлом кэша и репликой чтения.

Функционирование реплик чтения зависит от характеристик встроенной репликации Valkey или OSS Redis. Используя реплики чтения, следует учитывать потенциальное время отставания реплики от ее первичного узла кэша (так называемую противоречивость). ElastiCache создает метрику, чтобы помочь вам разобраться в сути противоречивости.

Плата за реплики чтения начисляется по той же схеме и тарифам, что и за стандартные узлы кэша. Как и при использовании стандартных узлов кэша, тариф за узел кэша в час для реплик чтения определяется классом узла кэша реплики чтения. Актуальные цены на ElastiCache см. здесь. За передачу данных при выполнении их репликации между первичным узлом кэша и репликой чтения плата не начисляется. Начисление платы за использование реплики чтения начинается сразу после ее успешного создания (с момента, когда ее состояние отобразится как «активное»). Плата за использование реплики чтения продолжает начисляться по стандартным почасовым тарифам для узлов кэша ElastiCache, пока не будет дана команда удалить ее.

Сервис ElastiCache поддерживает выполнение инициированной обработки отказа, при этом операции кэширования будут возобновлены в кратчайшие сроки. При выполнении обработки отказа ElastiCache изменяет запись DNS узла кэша таким образом, чтобы она указывала на реплику чтения, которая становится первичным узлом. Рекомендуется выполнить повторную попытку подключения к узлу кэша на уровне приложения. Как правило, выполнение всех пяти шагов занимает не более шести минут.

Это события автоматической обработки отказа, перечисленные в порядке возникновения:

1. Сообщение группы репликации: Test Failover API called for node group <node-group-id> (Вызов тестирования API обработки отказа для группы узлов <node-group-id>)
2. Сообщение кластера кэша: Failover from primary node <primary-node-id> to replica node <node-id> completed (Обработка отказа с передачей роли первичного узла от <primary-node-id> узлу реплики <node-id> завершена)
3. Сообщение группы репликации: Failover from primary node <primary-node-id> to replica node <node-id> completed (Обработка отказа с передачей роли первичного узла от <primary-node-id> узлу реплики <node-id> завершена)
4. Сообщение кластера кэша: Recovering cache nodes <node-id> (Восстановление узлов кэша <node-id>)
5. Сообщение кластера кэша: Recovering cache nodes <node-id> (Восстановление узлов кэша <node-id> завершено)

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

Да. Можно добавлять или удалять реплики чтения в одном либо нескольких сегментах кластерной среды. Во время этого процесса кластер остается доступным и обслуживает входящие операции ввода‑вывода.

Поддержка нескольких зон доступности позволяет работать в более высокодоступной конфигурации при разработке собственного кэша Elasticache. Все кэши бессерверной конфигурации Elasticache автоматически запускаются в нескольких зонах доступности. Группа репликации Elasticache состоит из первичного узла и не более чем пяти реплик чтения. Если используется несколько зон доступности, то по крайней мере одна реплика должна быть основной. При некоторых видах планового обслуживания или в маловероятном случае сбоя узла ElastiCache либо всей зоны доступности ElastiCache автоматически обнаружит сбой первичного узла, выберет реплику чтения и назначит ее новым первичным узлом. Кроме того, ElastiCache внесет изменения DNS, связанные с этой репликой чтения. Таким образом, если ваше приложение выполняет запись в основной узел, изменение адреса не потребуется.

Основные преимущества запуска Elasticache в нескольких зонах доступности – это повышение доступности и снижение потребности в администрировании. При запуске Elasticache в нескольких зонах доступности кэши соответствуют требованиям SLA на уровне 99,99 %. При сбое первичного узла Elasticache он будет недоступен для чтения и записи лишь в течение времени, требуемого для выполнения обработки отказа. Если используются возможности нескольких зон доступности, обработка отказа узла Elasticache выполняется автоматически и не требует никаких действий администратора.

Если вы используете Elasticache и у вас имеется группа репликации, состоящая из первичного узла и одной или нескольких реплик чтения, можно воспользоваться развертыванием в нескольких зонах доступности. В таких развертываниях Elasticache автоматически обнаруживает сбой первичного узла, выбирает одну из доступных реплик чтения и назначает ее новым первичным узлом. ElastiCache вносит изменения DNS, связанные с этой репликой чтения, и приложение продолжает выполнять запись в основной узел. Кроме того, ElastiCache будет пытаться создать новый узел для замены реплики чтения, которая была назначена основным узлом, в той же зоне доступности, где находился отказавший основной узел. В случае сбоя основного узла в связи с временным нарушением работы зоны доступности новая реплика будет запущена, как только работа зоны доступности возобновится.

Да. Обратите внимание на то, что размещение первичного узла и реплик в одной и той же зоне доступности не повысит устойчивость группы репликации Elasticache к сбоям в работе зоны доступности.

ElastiCache выполняет обработку отказа на реплику чтения в следующих случаях.

• Потеря доступности в зоне доступности первичного узла
• Потеря сетевого подключения к основному инстансу
• Сбой вычислительного блока основного инстанса

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

Да. ElastiCache создает событие, чтобы оповестить клиента об автоматическом выполнении обработки отказа. Для получения информации о событиях, связанных с узлом ElastiCache, воспользуйтесь DescribeEvents API или разделом Events (События) консоли управления ElastiCache.

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

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

Функция резервного копирования и восстановления позволяет создавать снимки состояния кэшей Elasticache. Сервис Elasticache сохраняет снимки состояния, которые впоследствии можно использовать для восстановления кэшей. В настоящее время это поддерживается ElastiCache для Valkey, ElastiCache для Redis OSS и бессерверными системами.

Снимки состояния будут полезны в случае потери данных по причине сбоя узла или в маловероятном случае сбоя аппаратного обеспечения. Кроме того, резервные копии часто используют при создании архивов. Снимки состояния томов помещаются в хранилище Amazon S3.

Да. Экспортировать снимки состояния Elasticache можно в авторизованную корзину S3, находящуюся в том же регионе, что и кэш.

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

Сервис Elasticache позволяет бесплатно хранить по одному снимку состояния для каждого активного инстанса кэша Elasticache. За хранение дополнительных снимков состояния плата начисляется на основании используемого объема хранилища по тарифу 0,085 USD/ГБ в месяц (единый тариф для всех регионов). Передача данных, связанных с использованием снимков состояния, не тарифицируется.

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

Программное ядро, используемое в Elasticache, полностью совместимо с ядром Valkey и OSS Redis, но в нем используются улучшения, которые повышают надежность, производительность и стабильность. Вот некоторые из улучшений.

• Больший объем используемой памяти. Теперь можно смело выделять приложениям больше памяти без риска увеличить использование подкачки во время синхронизации и записи снимков состояния.
• Улучшенная синхронизация. Более надежная синхронизация при высоких нагрузках и при восстановлении после разрывов связи в сети. Кроме того, синхронизация происходит быстрее, так как основной узел и реплики не используют для этой операции дисковые накопители.
• Более эффективная обработка отказов. В случае обработки отказа сегмент восстанавливается быстрее, так как реплики больше не выполняют очистку данных для полной повторной синхронизации с первичным узлом.

Улучшенное ядро полностью совместимо с ядром Valkey или OSS Redis, поэтому можно пользоваться повышенной надежностью и стабильностью без необходимости вносить изменения в код приложения.

Дополнительная плата за использование улучшенного ядра не взимается.

Шифрование данных при передаче и хранении, Valkey AUTH и управление доступом на основе ролей (RBAC) – это функции, которые можно выбрать при создании кэша ElastiCache. Если вы включили шифрование при передаче, то можете выбрать AUTH или RBAC, чтобы укрепить безопасность и улучшить управление доступом.

Шифрование данных при хранении предоставляет механизмы защиты от несанкционированного доступа к данным. Когда оно включено, производится шифрование следующих объектов.

• Диск во время синхронизации, резервного копирования и замены
• Резервные копии, хранящиеся в Amazon S3

Elasticache обеспечивает шифрование по умолчанию (управляемое сервисом) для данных при хранении, а также возможность использования собственных симметричных, управляемых клиентами ключей AWS KMS в сервисе AWS KMS. Дополнительные сведения см. в разделе о шифровании данных при хранении.

Функция шифрования данных при передаче упрощает шифрование всех данных, передаваемых между клиентами и сервером Elasticache, а также между серверами (первичными узлами и репликами чтения). Подробнее о шифровании данных при передаче в сервисе Elasticache.

Нет. Сервис ElastiCache самостоятельно управляет сроком действия сертификации и его обновлением. Для текущего обслуживания сертификатов никакие действия со стороны пользователя не требуются.

Нет. За использование шифрования дополнительная плата не взимается.

Глобальное хранилище данных – это функция ElastiCache, которая обеспечивает полностью управляемую, быструю, надежную и ориентированную на безопасность репликацию данных между регионами. Глобальное хранилище данных позволяет записывать данные в кэш в одном регионе и считывать их из не более чем двух других межрегиональных кластеров репликации, благодаря чему чтение и аварийное восстановление между регионами осуществляются с низкой задержкой.

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

Глобальное хранилище данных поддерживается в ElastiCache версии 7.2 для Valkey и ElastiCache версии 5.0.6 и более новых для OSS Redis.

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

Вы можете настроить глобальное хранилище данных, используя существующий кэш или создав новый, который будет использоваться в качестве основного. Вы можете создать глобальное хранилище данных всего за несколько шагов в консоли управления ElastiCache или загрузив последнюю версию AWS SDK либо AWS CLI. Глобальное хранилище данных поддерживается в AWS CloudFormation.

Нет. Сервис ElastiCache не производит автоматическое назначение вторичного кластера основным в случае ухудшения производительности основного кластера (региона). Вы можете запустить аварийное переключение вручную, назначив вторичный кластер основным. Аварийное переключение и назначение вторичного кластера основным обычно завершаются менее чем за одну минуту.

Сервис ElastiCache не предоставляет SLA в отношении RPO и RTO. Основным фактором для RPO является задержка репликации между регионами, которая зависит от задержек в сети между регионами и межрегиональной загруженности сети. RPO глобального хранилища данных обычно не превышает секунды, поэтому данные, записанные в первичном регионе, становятся доступны во вторичных регионах в течение одной секунды. RTO глобального хранилища данных составляет обычно менее минуты. Когда инициируется переключение на вторичный кластер, Elasticache обычно переводит вторичный кластер в режим полной поддержки чтения и записи менее чем за минуту.

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

Точный ответ на данный вопрос получить сложно, но при использовании ElastiCache не нужно беспокоиться об определении точного количества узлов, т. к. можно быстро добавить или удалить узлы позже. Можно также использовать бессерверную конфигурацию ElastiCache для упрощения работы высокодоступного кэша Memcached. При выборе первоначальной конфигурации рекомендуется учитывать следующие взаимосвязанные аспекты:

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

Требуемый объем памяти зависит от размера набора данных и схемы доступа приложения. Для повышения отказоустойчивости, получив общее представление о необходимом общем объеме памяти, разделите этот объем памяти на достаточное количество узлов таким образом, чтобы приложение могло нормально работать в случае потери одного или двух узлов. Например, если требуется 13 ГБ памяти, можно использовать два узла cache.m4.large вместо одного узла cache.m4.xlarge. Важно, чтобы в ходе восстановления после сбоя одного или нескольких узлов другие системы, такие как базы данных, не были перегружены при временном уменьшении частоты попаданий в кэш. Дополнительные сведения см. в руководстве пользователя ElastiCache.

Да. При создании кластера или добавлении узлов в существующий кластер можно выбрать зоны доступности для новых узлов. Вы можете либо указать запрашиваемое количество узлов в каждой зоне доступности, либо выбрать возможность распределения узлов по всем зонам. Если кластер находится в Amazon VPC, узлы можно размещать только в тех зонах доступности, которые входят в состав группы подсетей, выбранной для кэша. Дополнительные сведения см. в документации по ElastiCache VPC.

В каждом регионе можно запускать не более 300 узлов. Если требуется запустить большее количество, заполните форму запроса на увеличение лимитов ElastiCache.

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

• ElastiCache будет восстанавливать узел путем привлечения новых ресурсов и перенаправит существующее имя DNS узла так, чтобы оно указывало на новые ресурсы сервиса. Во время установки в Amazon VPC сервис ElastiCache при восстановлении узлов в случае сбоя обеспечивает неизменность как имени DNS, так и IP‑адреса узла. При установке вне Amazon VPC сервис ElastiCache обеспечивает неизменность имени DNS, однако основной IP‑адрес узла может измениться.
• Если связать тему SNS с кластером, после настройки нового узла и его готовности к использованию ElastiCache будет отправлять оповещение SNS о том, что произошло восстановление узла после сбоя. Это позволяет дополнительно адаптировать приложения, заставляя клиентскую библиотеку Memcached повторно подключаться к восстановленным узлам. Такая возможность может потребоваться, так как некоторые библиотеки Memcached перестают использовать сервер (узел) на неопределенный срок, если столкнутся с ошибками связи или тайм‑аутами для этого сервера.

Можно добавить больше узлов для существующего кластера с помощью операции Add Node (Добавить узел) на вкладке Nodes (Узлы) соответствующего кластера в консоли или путем вызова API ModifyCacheCluster.

ElastiCache является идеальной интерфейсной частью для таких сервисов AWS, как Amazon RDS и DynamoDB: он обеспечивает чрезвычайно низкую задержку для высокопроизводительных приложений и берет на себя некоторый объем запросов, в то время как другие сервисы обеспечивают продолжительную сохранность данных. Сервис также можно использовать для повышения производительности приложений в сочетании с Amazon EC2 и Amazon EMR.

Клиентские библиотеки Memcached доступны для многих, если не для всех популярных языков программирования. Если у вас возникли проблемы при использовании конкретного клиента Memcached с ElastiCache, сообщите нам на форуме сообщества ElastiCache.

ElastiCache не требует специальных клиентских библиотек и работает с существующими клиентскими библиотеками Memcached без перекомпиляции или повторного связывания приложений (Memcached 1.4.5 и более поздних версий). В качестве примера можно привести libMemcached (C) и другие библиотеки, основанные на ней (например, PHP, Perl, Python), spyMemcached (Java) и fauna (Ruby).

Auto Discovery – это возможность, которая экономит время и силы разработчиков, уменьшая сложность их приложений. Auto Discovery позволяет программным клиентам осуществлять автоматическое обнаружение узлов кэша, когда они добавляются или удаляются из кластера ElastiCache. Ранее для обработки изменений в составе кластера разработчикам необходимо было вручную обновлять список адресов узлов кэша. В зависимости от используемой архитектуры клиентского приложения обычно для инициализации клиента требовалось перезапускать приложение, что приводило к перерывам в работе. Благодаря возможности Auto Discovery сервис ElastiCache устраняет эту сложность. Используя Auto Discovery и обратную совместимость с протоколом Memcached, сервис ElastiCache предоставляет программным клиентам информацию о составе кластера кэша. Клиент, способный обрабатывать дополнительную информацию, без какой‑либо инициализации самостоятельно осуществляет перенастройку, чтобы использовать самые актуальные узлы кластера ElastiCache.

Кластер ElastiCache можно создать с узлами, обращение к которым осуществляется по именованным адресам. Auto Discovery аналогичным образом предоставляет кластеру ElastiCache уникальный адрес конфигурации, представляющий собой запись DNS, которая действует в течение всего срока использования кластера. Эта запись DNS содержит DNS‑имена узлов, которые входят в состав кластера. ElastiCache будет гарантировать, что адрес конфигурации всегда указывает хотя бы на один такой целевой узел. Запрос к целевому узлу возвращает адреса для всех узлов соответствующего кластера. После этого можно подключаться к узлам кластера обычным образом, а также использовать команды протокола Memcached, такие как get, set, incr и decr. Подробные сведения см. в документации. Для использования возможности Auto Discovery необходим клиент, совместимый с Auto Discovery. Клиенты Auto Discovery для Java и PHP можно загрузить в консоли ElastiCache. После инициализации клиент будет автоматически определять текущий состав кластера ElastiCache, используя адрес конфигурации. Когда в кластере кэша добавляются, удаляются или автоматически заменяются узлы после сбоя, клиент Auto Discovery автоматически определяет изменения, и инициализация клиентов вручную не требуется.

Чтобы начать работу, загрузите клиент кластера ElastiCache, нажав ссылку Download ElastiCache Cluster Client (Загрузить клиент кластера ElastiCache) в консоли ElastiCache. Для загрузки клиента требуется аккаунт ElastiCache. Если такой аккаунт еще не создан, можно зарегистрироваться на странице сведений об ElastiCache. После загрузки клиента можно приступить к настройке и активации кластера ElastiCache, открыв консоль ElastiCache. Подробнее об этом см. в документации.

Да. Прекратить использование Auto Discovery можно в любой момент. Чтобы отключить возможность Auto Discovery, укажите нужный режим работы при инициализации клиента кластера ElastiCache. Кроме того, благодаря поддержке Memcached сервисом ElastiCache, можно, как и прежде, просто использовать любой клиент, совместимый с протоколом Memcached.

Чтобы воспользоваться всеми возможностями Auto Discovery, для подключения к кластеру ElastiCache необходимо использовать клиент, совместимый с Auto Discovery. ElastiCache в настоящее время обеспечивает работу с клиентами, поддерживающими Auto Discovery, для .Net, Java и PHP. Их можно загрузить в консоли ElastiCache. У вас есть возможность создать клиентов для любого другого языка, взяв за основу доступные популярные клиенты Memcached.

Добавить поддержку возможности Auto Discovery можно к любой клиентской библиотеке Memcached. Инструкции по добавлению или изменению собственного клиента для обеспечения поддержки Auto Discovery см. в документации по набору команд Auto Discovery.

Да. Сервис ElastiCache по‑прежнему совместим с протоколами Memcached, поэтому в смене клиента необходимости нет. Однако чтобы использовать преимущества возможности Auto Discovery, мы расширили возможности клиента Memcached. Если вы не собираетесь использовать клиент кластера ElastiCache, можно продолжать работу с собственными клиентами или добавить поддержку набора команд Auto Discovery в свою клиентскую библиотеку.
 

Да. К одному и тому же кластеру ElastiCache одновременно можно подключаться с помощью клиента с поддержкой Auto Discovery и обычного клиента Memcached. Как и ранее, ElastiCache полностью совместим с протоколами Memcached.

Да. Прекратить использование Auto Discovery можно в любой момент. Чтобы отключить возможность Auto Discovery, укажите нужный режим работы при инициализации клиента кластера ElastiCache. Кроме того, благодаря поддержке Memcached сервисом ElastiCache, можно, как и прежде, просто использовать любой клиент, совместимый с протоколом Memcached.

ElastiCache позволяет пользователю самостоятельно принимать решение об обновлении используемого кластером ПО, совместимого с протоколом Memcached, до новых версий, поддерживаемых ElastiCache, а также о времени этого обновления. Благодаря этому можно гибко обеспечивать совместимость с определенными версиями Memcached, тестировать работу приложения с новыми версиями перед развертыванием в рабочей среде и выполнять обновления версий по своему собственному графику. В связи с тем, что обновление версий сопряжено с некоторым риском несовместимости, оно не выполняется автоматически и должно быть инициировано пользователем. Таким образом, вы самостоятельно управляете процессом обновления версий ПО, но всю трудоемкую работу по применению обновлений выполняет сервис ElastiCache. В последующих пунктах вопросов и ответов подробнее рассказывается об управлении версиями. См. также информацию по данной теме в Руководстве пользователя ElastiCache. Хотя возможности управления версиями ядра позволяют пользователям максимально контролировать процесс обновления, мы сохраняем за собой право самостоятельно применять исправления к кластеру в случае обнаружения любых уязвимостей, касающихся безопасности системы или ПО кэширования.

Можно указать любую из поддерживаемых в настоящее время версий (второстепенную или основную) при создании нового кластера. Чтобы инициировать обновление до той или иной поддерживаемой версии сервиса, используйте параметр Modify (Изменить) соответствующего кластера. В поле Cache Engine Version (Версия сервиса кэша) укажите версию, до которой хотите выполнить обновление. При этом обновление будет применено либо сразу же (если установлен флажок Applied Immediately), либо во время следующего запланированного интервала обслуживания кластера.

Да. Это можно сделать, создав новый кластер с новой версией сервиса. Можно направить приложение, находящееся на стадии разработки или тестирования, на этот кластер, протестировать его и принять решение об обновлении основного кластера.

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

Существующий кластер Memcached можно обновить с помощью процесса Modify. При обновлении старых версий Memcached до версии 1.4.33 и новее удостоверьтесь, что используемое значение параметра max_chunk_size удовлетворяет условиям, необходимым параметру slab_chunk_max. Ознакомьтесь с предварительными требованиями для обновления.

Elasticache предоставляет улучшенные потоки ввода-вывода, которые значительно повышают пропускную способность и сокращают задержки при масштабировании за счет мультиплексирования, разгрузки уровня представления и многого другого. Усовершенствованные потоки ввода-вывода повышают производительность за счет использования большего количества ядер для обработки операций и динамической адаптации к рабочей нагрузке. Elasticache повышает пропускную способность кластеров с поддержкой протокола TLS за счет переноса шифрования на те же усовершенствованные потоки ввода-вывода. В Elasticache (OSS Redis) версии 7.0 появилось улучшенное мультиплексирование ввода-вывода, которое объединяет множество клиентских запросов в один канал и повышает эффективность потока.

В ElastiCache для OSS Redis версии 7.1 расширена функциональность усовершенствованных потоков ввода-вывода, чтобы они также обрабатывали логику уровня представления. Они не только считывают входные данные клиента, но и анализируют их в двоичном формате команд, которые затем передаются в основной поток для выполнения, чтобы повысить производительность. С помощью Elasticache версии 7.1 для OSS Redis можно добиться увеличения пропускной способности на 100 % и снижения задержки P99 на 50 % по сравнению с предыдущей версией. На инстансе r7g.4xlarge и выше можно обрабатывать более 1 миллиона запросов в секунду (RPS) на узел.

Elasticache предоставляет два разных набора метрик для измерения использования ЦП кэша в зависимости от выбранного варианта развертывания кэша. При использовании бессерверной конфигурации ElastiCache можно отслеживать загрузку ЦП с помощью метрики ElastiCache Processing Units (ECPU). Количество ECPU, используемых вашими запросами, зависит от времени, затраченного виртуальным ЦПУ, и объема переданных данных. Для каждого простого чтения и записи, например команд OSS Redis GET и SET или команд Memcached get и set, требуется 1 ECPU на каждый переданный килобайт (КБ) данных. Некоторые команды OSS Redis, работающие со структурами данных в памяти, могут дольше использовать виртуальное ЦПУ, чем команды GET или SET. ElastiCache вычисляет количество использованных ECPU на основе времени, затраченного на выполнение команды виртуальным процессором, по сравнению с базовым показателем времени его работы, затрачиваемого командой SET или GET. Если выполнение команды занимает дополнительное время использования виртуального процессора и передает больше данных, чем 1 ECPU при базовой производительности, Elasticache рассчитывает необходимое количество процессоров на основе большего из двух параметров.

При проектировании собственного кластера вы можете отслеживать метрики EngineCPUUtilization и CPUUtilization. Метрика CPUUtilization оценивает загрузку ЦП для каждого инстанса (узла), а EngineCPUUtilization – общую загрузку ЦП на уровне процесса ядра. Метрика EngineCPUUtilization введена в дополнение к метрике CPUUtilization, так как основной процесс OSS Redis является однопоточным и использует только одно ядро из всех доступных на инстансе ядер ЦП. Соответственно, метрика CPUUtilization не отражает в полной мере степень загрузки ЦП на уровне процесса ядра. Для того чтобы точно понимать фактическую загрузку ЦП на кластерах OSS Redis, рекомендуется использовать сочетание метрик CPUUtilization и EngineCPUUtilization.

Оба набора метрик доступны во всех регионах AWS, а работать с ними можно с помощью сервиса Amazon CloudWatch или в консоли. Кроме того, мы рекомендуем ознакомиться с документацией, чтобы узнать о полезных метриках для мониторинга производительности.

Реплики чтения в OSS Redis служат для:

• обработки сбоев;
• масштабирования при обслуживании запросов чтения.

При запуске кэша как реплики чтения первичный узел обслуживает процессы записи и чтения. Реплика обслуживает исключительно трафик чтения, а также доступна в среде теплого резервирования на случай повреждения первичного узла.

В бессерверной конфигурации Elasticache реплики чтения автоматически поддерживаются сервисом. При проектировании собственного кэша развертывание одной и более реплик чтения для данного первичного узла успешно применяется в различных сценариях. Ниже перечислены самые распространенные из них.

• Масштабирование вычислительных ресурсов или ресурсов ввода‑вывода одного первичного узла для выполнения рабочих нагрузок с большим количеством операций чтения. Избыточный трафик чтения можно направить на одну и более реплик чтения.
• Обслуживание трафика чтения в случае недоступности первичного узла. Если первичный узел не принимает запросы ввода‑вывода (например, в связи с приостановкой ввода‑вывода во время выполнения резервного копирования или запланированного обслуживания), трафик операций чтения можно направить на реплики чтения. Следует учесть, что в этом случае данные, которые содержит реплика чтения, могут оказаться устаревшими вследствие недоступности основного инстанса. Реплику чтения также можно использовать для перезапуска отказавшего первичного узла.
• Сценарии защиты данных. В маловероятном случае сбоя первичного узла или зоны доступности, в которой он находится, реплику чтения в другой зоне доступности можно назначить новым первичным узлом. 

Вы можете подключиться к реплике чтения так же, как и к первичному узлу кэша. Порядок распределения трафика чтения по множеству реплик чтения определяется приложением. Дополнительные сведения.

• Кластеры OSS Redis (режим кластера отключен) используют отдельные адреса узла для операций чтения (в API и CLI они называются адресами чтения).
• Кластеры OSS Redis (режим кластера включен) используют для всех адресов конфигурации кластера. Кроме того, выполнять операции чтения по-прежнему можно из адресов узлов (в API и CLI они называются адресами чтения).

ElastiCache позволяет создать не более пяти (5) реплик чтения для одного первичного узла кэша.

В случае аварийного переброса репликация всех связанных и доступных реплик чтения автоматически возобновится сразу же по завершении переброса (с применением обновлений, которые содержатся в репликах, ставших основными).

Обновления первичного узла кэша автоматически реплицируются во все связанные реплики чтения. Однако в связи с применением поддерживаемой OSS Redis асинхронной репликации обновления реплики чтения могут отставать от обновлений соответствующего первичного узла кэша. Ниже перечислены наиболее частые причины такого отставания.

• Объем операций ввода‑вывода при записи в первичный узел кэша превышает скорость применения обновлений к реплике чтения.
• Сетевое разграничение или задержка между первичным узлом кэша и репликой чтения.

Функционирование реплик чтения зависит от характеристик встроенной репликации OSS Redis. Используя реплики чтения, следует учитывать потенциальное время отставания реплики от ее первичного узла кэша (так называемую противоречивость). ElastiCache отправляет значения метрики для анализа несогласованности.

Плата за реплики чтения начисляется по той же схеме и тарифам, что и за стандартные узлы кэша. Как и при использовании стандартных узлов кэша, тариф за узел кэша в час для реплик чтения определяется классом узла кэша реплики чтения. Актуальные цены на ElastiCache см. здесь. За передачу данных при выполнении их репликации между первичным узлом кэша и репликой чтения плата не начисляется. Начисление платы за использование реплики чтения начинается сразу после ее успешного создания (с момента, когда ее состояние отобразится как «активное»). Плата за использование реплики чтения продолжает начисляться по стандартным почасовым тарифам для узлов кэша ElastiCache, пока не будет дана команда удалить ее.

Сервис ElastiCache поддерживает выполнение инициированной обработки отказа, при этом операции кэширования будут возобновлены в кратчайшие сроки. При выполнении обработки отказа ElastiCache изменяет запись DNS узла кэша таким образом, чтобы она указывала на реплику чтения, которая становится первичным узлом. Рекомендуется выполнить повторную попытку подключения к узлу кэша на уровне приложения. Как правило, выполнение всех пяти шагов занимает не более шести минут.

Это события автоматической обработки отказа, перечисленные в порядке возникновения:

1. Сообщение группы репликации: Test Failover API called for node group <node-group-id> (Вызов тестирования API обработки отказа для группы узлов <node-group-id>)
2. Сообщение кластера кэша: Failover from primary node <primary-node-id> to replica node <node-id> completed (Обработка отказа с передачей роли первичного узла от <primary-node-id> узлу реплики <node-id> завершена)
3. Сообщение группы репликации: Failover from primary node <primary-node-id> to replica node <node-id> completed (Обработка отказа с передачей роли первичного узла от <primary-node-id> узлу реплики <node-id> завершена)
4. Сообщение кластера кэша: Recovering cache nodes <node-id> (Восстановление узлов кэша <node-id>)
5. Сообщение кластера кэша: Recovering cache nodes <node-id> (Восстановление узлов кэша <node-id> завершено)

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

Да. Увидеть местоположение текущего первичного узла можно в консоли или с помощью DescribeCacheClusters API.

Да. Можно добавлять или удалять реплики чтения в одном либо нескольких сегментах кластерной среды. Во время этого процесса кластер остается доступным и обслуживает входящие операции ввода‑вывода.

Поддержка нескольких зон доступности позволяет работать в более высокодоступной конфигурации при разработке собственного кэша Elasticache. Все кэши бессерверной конфигурации Elasticache автоматически запускаются в нескольких зонах доступности. Группа репликации Elasticache состоит из первичного узла и не более чем пяти реплик чтения. Если используется несколько зон доступности, то по крайней мере одна реплика должна быть основной. При некоторых видах планового обслуживания или в маловероятном случае сбоя узла ElastiCache либо всей зоны доступности ElastiCache автоматически обнаружит сбой первичного узла, выберет реплику чтения и назначит ее новым первичным узлом. Кроме того, ElastiCache внесет изменения DNS, связанные с этой репликой чтения. Таким образом, если ваше приложение выполняет запись в основной узел, изменение адреса не потребуется.

Основные преимущества запуска Elasticache в нескольких зонах доступности – это повышение доступности и снижение потребности в администрировании. При запуске Elasticache в нескольких зонах доступности кэши соответствуют требованиям SLA на уровне 99,99 %. При сбое первичного узла Elasticache он будет недоступен для чтения и записи лишь в течение времени, требуемого для выполнения обработки отказа. Если используются возможности нескольких зон доступности, обработка отказа узла Elasticache выполняется автоматически и не требует никаких действий администратора. 

Если вы используете Elasticache и у вас имеется группа репликации, состоящая из первичного узла и одной или нескольких реплик чтения, можно воспользоваться развертыванием в нескольких зонах доступности. В таких развертываниях Elasticache автоматически обнаруживает сбой первичного узла, выбирает одну из доступных реплик чтения и назначает ее новым первичным узлом. ElastiCache вносит изменения DNS, связанные с этой репликой чтения, и приложение продолжает выполнять запись в основной узел. Кроме того, ElastiCache будет пытаться создать новый узел для замены реплики чтения, которая была назначена основным узлом, в той же зоне доступности, где находился отказавший основной узел. В случае сбоя основного узла в связи с временным нарушением работы зоны доступности новая реплика будет запущена, как только работа зоны доступности возобновится.

Да. Обратите внимание на то, что размещение первичного узла и реплик в одной и той же зоне доступности не повысит устойчивость группы репликации Elasticache к сбоям в работе зоны доступности. Кроме того, размещение реплик в той же зоне доступности, что и первичный узел, будет запрещено, если включена поддержка нескольких зон доступности.

ElastiCache выполняет обработку отказа на реплику чтения в следующих случаях.

• Потеря доступности в зоне доступности первичного узла
• Потеря сетевого подключения к основному инстансу
• Сбой вычислительного блока основного инстанса

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

Да. ElastiCache создает событие, чтобы оповестить клиента об автоматическом выполнении обработки отказа. Для получения информации о событиях, связанных с узлом ElastiCache, воспользуйтесь API DescribeEvents или разделом Events (События) в консоли управления ElastiCache.

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

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

Функция резервного копирования и восстановления позволяет создавать снимки состояния кэшей Elasticache. Сервис Elasticache сохраняет снимки состояния, которые впоследствии можно использовать для восстановления кэшей. В настоящее время это поддерживается ElastiCache для Valkey, ElastiCache для Redis OSS и бессерверными системами. 

Снимки состояния будут полезны в случае потери данных по причине сбоя узла или в маловероятном случае сбоя аппаратного обеспечения. Кроме того, резервные копии часто используют при создании архивов. Снимки состояния томов помещаются в хранилище Amazon S3.

При запуске резервного копирования сервис Elasticache создает снимок состояния указанного кэша, который впоследствии можно будет использовать для восстановления или архивации. Резервное копирование можно запустить в любой момент. Можно также настроить регулярное ежедневное резервное копирование со сроком хранения копий до 35 дней. При выборе снимка состояния для восстановления будет создан новый кэш Elasticache, содержащий данные этого снимка состояния. Снимки состояний Elasticache совместимы с форматом файлов OSS Redis RDB.

Функцию резервного копирования и восстановления можно использовать с помощью консоли, ElastiCache API и AWS CLI. Выполнение этих функций можно в любой момент прекратить или запустить снова.

Возможность резервного копирования и восстановления позволяет создавать снимки состояния для каждого кэша. Можно выбрать кэш Elasticache, резервную копию которого требуется создать, в консоли, с помощью AWS CLI или ElastiCache API. Рекомендуется выполнять резервное копирование одного кэша реплик чтения для минимизации возникновения задержек в работе первичного узла. При использовании бессерверной конфигурации Elasticache резервное копирование реплик чтения выполняется автоматически.

Да. Экспортировать снимки состояния Elasticache можно в авторизованную корзину S3, находящуюся в том же регионе, что и кэш.

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

Сервис Elasticache позволяет бесплатно хранить по одному снимку состояния для каждого активного инстанса кэша Elasticache. За хранение дополнительных снимков состояния плата начисляется на основании используемого объема хранилища по тарифу 0,085 USD/ГБ в месяц (единый тариф для всех регионов). Передача данных, связанных с использованием снимков состояния, не тарифицируется.

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

Программное ядро, используемое в Elasticache, полностью совместимо с ядром OSS Redis, но в нем используются улучшения, которые повышают надежность, производительность и стабильность. Вот некоторые из улучшений.

• Больший объем используемой памяти. Теперь можно смело выделять приложениям больше памяти без риска увеличить использование подкачки во время синхронизации и записи снимков состояния.
• Улучшенная синхронизация. Более надежная синхронизация при высоких нагрузках и при восстановлении после разрывов связи в сети. Кроме того, синхронизация происходит быстрее, так как основной узел и реплики не используют для этой операции дисковые накопители.
• Более эффективная обработка отказов. В случае обработки отказа сегмент восстанавливается быстрее, так как реплики больше не выполняют очистку данных для полной повторной синхронизации с первичным узлом.
• Разгрузка TLS и мультиплексирование операций ввода-вывода. Сервис ElastiCache разработан для более эффективного использования доступных ресурсов процессора путем обработки определенных сетевых процессов в выделенных потоках.

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

Дополнительная плата за использование улучшенного ядра не взимается.

Шифрование данных при хранении предоставляет механизмы защиты от несанкционированного доступа к данным. Когда оно включено, производится шифрование следующих объектов.

• Диск во время синхронизации, резервного копирования и замены
• Резервные копии, хранящиеся в Amazon S3

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

Функция шифрования данных при передаче упрощает шифрование всех данных, передаваемых между клиентами и сервером Elasticache, а также между серверами (первичными узлами и репликами чтения). Подробнее о шифровании данных при передаче в сервисе ElastiCache.

Шифрование данных при передаче и хранении, OSS Redis AUTH и управление доступом на основе ролей (RBAC) – это функции, которые можно выбрать при создании кэша Elasticache. Если вы включили шифрование при передаче, то можете выбрать OSS Redis AUTH или RBAC, чтобы укрепить безопасность и улучшить управление доступом.

Нет. Сервис ElastiCache самостоятельно управляет сроком действия сертификации и его обновлением. Для текущего обслуживания сертификатов никакие действия со стороны пользователя не требуются.

Нет. За использование шифрования дополнительная плата не взимается.

Глобальное хранилище данных – это функция ElastiCache, которая обеспечивает полностью управляемую, быструю, надежную и ориентированную на безопасность репликацию данных между регионами. Глобальное хранилище данных позволяет записывать данные в кэш в одном регионе и считывать их из не более чем двух других межрегиональных кластеров репликации, благодаря чему чтение и аварийное восстановление между регионами осуществляются с низкой задержкой.

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

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

Глобальное хранилище данных поддерживается сервисом ElastiCache для Redis версии 5.0.6 и выше.

Нет. Сервис ElastiCache не производит автоматическое назначение вторичного кластера основным в случае ухудшения производительности основного кластера (региона). Вы можете запустить аварийное переключение вручную, назначив вторичный кластер основным. Аварийное переключение и назначение вторичного кластера основным обычно завершаются менее чем за одну минуту.

Глобальное хранилище данных обеспечивает более высокую безопасность данных благодаря использованию шифрования при передаче межрегионального трафика. Кроме того, можно использовать шифрование данных при хранении, чтобы зашифровать основные и вторичные кэши, а также лучше защитить данные. В каждом первичном и вторичном кэше может быть отдельный ключ AWS KMS, управляемый клиентом, для шифрования при хранении.

Сервис ElastiCache не предоставляет SLA в отношении RPO и RTO. Основным фактором для RPO является задержка репликации между регионами, которая зависит от задержек в сети между регионами и межрегиональной загруженности сети. RPO глобального хранилища данных обычно не превышает секунды, поэтому данные, записанные в первичном регионе, становятся доступны во вторичных регионах в течение одной секунды. RTO глобального хранилища данных составляет обычно менее минуты. Когда инициируется переключение на вторичный кластер, Elasticache обычно переводит вторичный кластер в режим полной поддержки чтения и записи менее чем за минуту.

Сервис ElastiCache не предоставляет SLA в отношении RPO и RTO. Основным фактором для RPO является задержка репликации между регионами, которая зависит от задержек в сети между регионами и межрегиональной загруженности сети. RPO глобального хранилища данных обычно не превышает секунды, поэтому данные, записанные в первичном регионе, становятся доступны во вторичных регионах в течение одной секунды. RTO глобального хранилища данных составляет обычно менее минуты. Когда инициируется переключение на вторичный кластер, Elasticache обычно переводит вторичный кластер в режим полной поддержки чтения и записи менее чем за минуту.

Многоуровневое хранение данных кардинально меняет соотношение цены и производительности за счет использования более дешевых твердотельных накопителей (SSD) в каждом узле кластера в дополнение к хранению данных в памяти. Это идеальный вариант для рабочих нагрузок, которым регулярно требуется доступ к 20 % от всего набора данных, а также приложений, для которых не имеет значения дополнительная задержка при обращении к данным на SSD. По сравнению с узлами Elasticache R6g, располагающими только памятью, у узлов Elasticache R6gd с памятью и твердотельными накопителями емкость хранилища почти в 5 раз больше. Благодаря этому экономия клиентов при максимальной нагрузке составляет более 60 %.

Многоуровневое хранение данных работает автоматически и прозрачно: когда доступный объем памяти заканчивается, элементы, которые дольше всего не использовались, перемещаются на локально подключенные твердотельные накопители (SSD) NVMe. Если в дальнейшем осуществляется доступ к элементу, хранящемуся на SSD, ElastiCache перед обслуживанием запроса асинхронно возвращает элемент в память.

Многоуровневое хранение данных оказывает минимальное влияние на производительность приложений. Например, при значении строк в 500 байт дополнительная задержка для запросов к данным на твердотельном накопителе в среднем составит 300 мкс по сравнению с запросами к данным в памяти.

Elasticache поддерживает многоуровневое хранение данных в ElastiCache для OSS Redis версии 6.2 и более новых версий.

Elasticache поддерживает многоуровневое хранение данных в кластерах с использованием узлов R6gd.

При использовании многоуровневого хранения данных поддерживаются все команды Valkey и OSS Redis и большая часть функций ElastiCache. Функции, которые не поддерживаются в кластерах с многоуровневым хранением данных, перечислены в документации.

Начисляется только почасовая плата за использование узла; дополнительная плата за многоуровневое хранение данных не взимается. Узлы с многоуровневым хранением данных предлагаются как зарезервированные узлы с тарифами по требованию. Цены на ElastiCache см. здесь.