AWS становится постоянным с MemoryDB для Redis

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

Amazon MemoryDB для Redis – это база данных в памяти, которая также автоматически и незаметно сохраняет данные на уровне хранения. Барри Моррис, генеральный менеджер Amazon Web Services (AWS), рассказал нам о решении компании создать сервис и о том, как он сочетается с существующими предложениями AWS в памяти.

Адаптация к меняющейся архитектуре

Вчерашние приложения были в основном монолитными, с одной базой кода, обращающейся к внутренней базе данных. «Все меняется, – говорит Моррис. По мере того, как разработчики переходят к моделям на основе микросервисов, обычно основанным на контейнерах, управляемых Kubernetes, они создают программные приложения в виде наборов небольших компонентов, которые взаимодействуют друг с другом.

Эти изменения в архитектуре приложения влияют на базу данных. Теперь, когда пользователь нажимает на веб-страницу или другое приложение выполняет вызов API, сотни независимых микросервисов в фоновом режиме делают свои собственные запросы к базе данных. Затем структура микросервисов втягивает все это в ответ. Это вызывает одновременный доступ ко многим базам данных.

«Проблема в том, что вся ваша сквозная задержка для ответа пользователю составляет менее полсекунды, а может быть, намного меньше, если они используют определенные приложения через соединение 5G», – говорит Моррис. Это потенциально проблематично, если каждый из сотен микросервисов выполняет свои собственные вызовы к базе данных. «Итак, что вам нужно, так это доступ к базе данных с очень малой задержкой».

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

Традиционно у пользователей AWS было два варианта работы с наборами данных в памяти: Redis и собственный сервис Amazon ElastiCache. Теперь компания предлагает MemoryDB в качестве третьего варианта. Почему?

В поисках долговечности в памяти

Redis пользуется популярностью, поскольку пять лет подряд он получил звание самой любимой базы данных в опросе разработчиков Stack Overflow. Это означает, что у него также есть хорошо зарекомендовавшая себя база разработчиков. По словам Морриса, он идеально подходит для многих приложений баз данных в оперативной памяти, но AWS по-прежнему считает, что в нем есть пробелы, которые оставляют место для альтернативы.

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

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

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

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

Redis действительно включает некоторые параметры сохранения. Сегодня с Redis пользователи могут создавать моментальные снимки на определенный момент времени или использовать файлы только для добавления, которые записывают файлы в журналы сохраняемости, которые восстанавливают данные при перезапуске сервера. Однако у каждого есть свои недостатки; в моментальных снимках не будут сохраняться самые свежие данные, в то время как опция «только добавление» создает относительно большие файлы и может повлиять на задержку. Вы можете объединить их, чтобы получить лучший вариант сохранения в Redis. Даже в этом случае данные, которые хранятся на реальных дисках каждого узла для самоуправляемого Redis, могут быть потеряны, если этот узел будет затронут.

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

«Теперь вы задаетесь вопросом, как управлять всем этим, если вы управляете им самостоятельно», – утверждает он. «Как вы делаете резервное копирование? Как вы делаете исправления, чтобы ваша система не выходила из строя?»

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

«Когда вы перекладываете все эти задачи на свою собственную команду, а не поручаете их людям, которые просто делают это весь день, на это приходится огромная сумма затрат», – говорит он, добавляя, что в некоторых случаях руководство может проглотить 80 процентов бюджета жизненного цикла базы данных.

Сочетание производительности и настойчивости

Здесь на помощь приходит MemoryDB. Это управляемая база данных в памяти, полностью совместимая с Redis, как и ElastiCache. Разница в том, что он обеспечивает постоянство на диске. «Это полная надежность с тремя зонами доступности», – объясняет он. «Он хранит данные в независимых инфраструктурах центров обработки данных».

AWS не слишком много говорит о том, что происходит под капотом. Идея в том, что это невидимо для пользователя. Если база данных выйдет из строя, данные будут по-прежнему доступны при восстановлении, и пользователю не нужно будет ничего делать. Моррис скажет, что он использует распределенные журналы транзакций для достижения устойчивости.

Журнал транзакций хранится в отдельной, надежной и высокодоступной серверной службе, которая используется в качестве строительного блока MemoryDB. Это сетевые API-интерфейсы, которые передают данные из оперативной памяти в внутреннюю инфраструктуру хранения. MemoryDB также делает снимки, как и Redis. Моментальные снимки и журнал позволяют базе данных восстанавливать и сохранять самое последнее состояние базы данных из постоянного хранилища.

«Этот процесс полностью невидим для пользователя», – говорит Моррис, добавляя, что эта реконструкция вызывается только тогда, когда база данных выходит из строя. «Мы просто восстанавливаем данные, когда это необходимо».

Слияние кешей с постоянными базами данных

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

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

«Для многих из них это сложно, дорого и болезненно, потому что этим трудно управлять и трудно масштабировать», – объясняет он. «Они говорят:« Я храню эти данные в одном месте, чтобы обеспечить надежность, а в другом – для повышения производительности. Могу ли я иметь и то, и другое в одном месте? »»

Хотя MemoryDB устраняет необходимость в отдельном постоянном хранилище и хранилище в памяти, Моррис признает, что людям часто требуется интегрировать базу данных с другими облачными сервисами и базами данных для поддержки своих вариантов использования. AWS Lambda, платформа бессерверных функций компании, поддерживает интеграцию с базами данных, позволяя событиям хранилища запускать внешние функции. Компания также анонсировала AWS Glue Elastic Views, который создает материализованные представления одной базы данных в контексте другой.

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

AWS еще не объявила о планах по созданию бессерверной версии MemoryDB, что означает, что сервис основан на экземплярах. Почасовая стоимость инстанса – один из трех факторов, определяющих цену MemoryDB. Два других – это цена за записанные данные и стоимость хранения моментальных снимков за гигабайт. Нет никаких затрат на чтение.

По мнению Морриса, добавление MemoryDB к текущему списку предложений управляемых баз данных AWS не ограничивает существующих пользователей Redis или ElastiCache на AWS. «Это выбор, и хотя это не для всех, есть определенные клиенты, которым действительно нужна эта функциональность», – говорит он.

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

При поддержке AWS.