Решения для реплицированного кэширования, совместимые с AWS

Мой вариант использования следующий:

У нас есть около 500 серверов, работающих в автомасштабируемом кластере EC2, которым требуется доступ к одним и тем же данным конфигурации (разложенным по принципу «ключ-значение») несколько миллионов раз в секунду.

Данные конфигурации не очень большие (1 или 2 ГБ) и не сильно меняются (несколько десятков обновлений / удалений / вставок в минуту в пиковое время).

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

Конечная согласованность - это нормально. Однако нам нужно убедиться, что каждое обновление будет распространяться в какой-то момент. (зная, что серверы могут быть отключены в любое время). Распространение обновлений по серверам должно быть надежным и простым в настройке (у нас не может быть статических IP-адресов для наших серверов, или мы не хотим идти по пути «подделки» многоадресная рассылка на AWS и т. д.)

Вот решения, которые мы изучали в прошлом:

  • Использование обычных Java-карт и использование нашей специально созданной системы для распространения обновлений по кластеру. (очевидно, он не так хорошо масштабируется)
  • Использование EhCache и его функции репликации. Но настраивать его на EC2 очень болезненно и как-то ненадежно.

Вот решения, которые мы собираемся попробовать:

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

Вот что я нашел на данный момент:

  • Реплицированная карта Hazelcast является недавней и все еще немного ненадежной (асинхронные обновления могут быть потеряны в случае уменьшения масштаба)
  • Похоже, что Geode стал "стабильным" сравнительно недавно (хотя он предположительно находится в разработке с начала 2000-х).
  • Похоже, что Ignite может подойти, но я не уверен, как их система на основе обнаружения S3 будет работать, если мы будем продолжать регулярно добавлять / удалять узел.

Спасибо!


amazon-web-services caching hazelcast ignite geode
person Maxime    schedule 14.02.2017    source источник
comment
Geode - это версия Gemfire с открытым исходным кодом. и Gemfire существует довольно давно. Когда вы проводите исследование, может быть полезно поискать обсуждение, связанное с Gemfire, поскольку по основам Gemfire и Geode работают почти одинаково.   -  person Xiawei Zhang    schedule 15.02.2017

Ответы (3)


arrow_upward
3
arrow_downward

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

Что касается конфигурации, вам нужно будет запустить процессы обнаружения пары / нескольких элементов (локаторы Geode) и указать каждому элементу эти локаторы. (Мы рекомендуем вам запустить один локатор / зону доступности и использовать 3 зоны доступности для защиты от разделения сети).

Geode / GemFire ​​некоторое время работает стабильно; обеспечение требований к низкой задержке и высокой масштабируемости для систем бронирования на индийских и китайских железных дорогах среди других пользователей в течение очень долгого времени.

Раскрытие информации: я являюсь коммиттером Geode.

person Swapnil    schedule 15.02.2017
comment
Если я выберу синхронную репликацию, придется ли мне ждать, пока обновление будет распространено на 500 серверов? Или он просто удостоверится, что реплицируется хотя бы на одном / двух / трех серверах? Вы также упомянули, что обнаружение происходит с использованием процессов обнаружения. Работает ли он и в регионах AWS? - person Maxime; 15.02.2017
comment
Я рекомендую решение Swapnil вместе с архитектурным шаблоном CQRS для обработки ваших обновлений посредством конечной согласованности. Я внес это решение в книгу Вона «Реализация доменно-ориентированного дизайна» несколько лет назад с помощью GemFire. Ваши миллионы операций чтения в секунду поступают из кластера, доступного только для чтения, через ваши узлы и оптимизированы для чтения. Кластер меньшего размера предназначен для записи и оптимизирован для агрегатов записи. Естественный гарантированный механизм асинхронной обработки событий Geode будет передавать обновления в ваш кластер чтения для обновления. Geode имеет здесь преимущество с гарантированными асинхронными событиями и CQ. - person Wes Williams; 16.02.2017
comment
Что касается процесса обнаружения, да, он будет работать во всех регионах AWS, пока виден IP. Локаторы существуют для обеспечения высокой масштабируемости, простоты управления и защиты от разделения мозга. Geode гарантирует, что реплики находятся в разных зонах доступности для защиты согласованности. Если ваша задержка между регионами велика, вы можете выбрать шлюз глобальной сети Geode, чтобы гарантировать обновления. Шлюз WAN уже много лет используется почти всеми крупными банками США для тиражирования. См. geode.apache.org/docs/guide/topologies_and_comm/ - person Wes Williams; 16.02.2017
comment
В зависимости от ваших требований и топологии региона существуют более простые решения, но мне потребуется дополнительная информация, чтобы дать убедительную рекомендацию. Еще одно соображение - использовать клиент Geode в качестве CACHING_PROXY, а регион сервера (или кеш) - как разделенный регион. Случайные записи легко обрабатываются разделенной областью. Ваши чтения в миллионы секунд легко обрабатываются клиентом кэширования в локальной памяти. Все клиенты обновляются, когда происходит обновление сервера, через гарантированную подписку на события. Проще, чем CQRS, и гораздо меньше узлов. Зависит от # клиентов, # регионов, # серверов / региона. - person Wes Williams; 16.02.2017

arrow_upward
1
arrow_downward

Ignite обеспечивает встроенную интеграцию AWS для обнаружения через хранилище S3: https://apacheignite-mix.readme.io/docs/amazon-aws. Это решает основную проблему - вам не нужно менять конфигурацию при перезапуске экземпляров. Вкратце, любые узлы, которые успешно присоединяются к топологии, записывают свои координаты в корзину (и удаляют их при выходе из строя или выходе из строя). Когда вы запускаете новый узел, он считывает это ведро и подключается к одному из перечисленных адресов.

person Valentin Kulichenko    schedule 15.02.2017

arrow_upward
1
arrow_downward

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

  1. Создайте кластер Hazelcast с набором узлов в зависимости от размера данных.
  2. Создайте распределенную карту (IMap) и настройте конфигурации подсчета и выселения в зависимости от размера / количества пар ключ / значение. Данные распределяются по всем узлам.
  3. Настройте счетчик резервных копий в зависимости от того, насколько критичны данные и сколько времени требуется, чтобы извлечь данные из фактического источника (БД / файлы). По умолчанию распределенные карты имеют 1 резервную копию.
  4. На стороне клиента настройте NearCache и прикрепите его к распределенной карте. Этот NearCache будет содержать пару ключ / значение на самой стороне клиента / на стороне клиента. Таким образом, операции get завершатся за миллисекунды.

Что следует учитывать при использовании решения NearCache:

  • Первая операция получения будет медленнее, так как она должна проходить через сеть, чтобы получить данные из кластера.
  • Аннулирование кэша не является полностью надежным, поскольку будет задержка синхронизации с кластером и может закончиться чтение устаревших данных. Опять же, это тот же случай для всех решений для кеширования.
  • Клиент несет ответственность за установку тайм-аута и аннулирование записей Nearcache. Чтобы будущие тягачи получали свежие данные из кластера. Это зависит от того, как часто обновляются данные или заменяется значение ключа.
person A.K.Desai    schedule 17.02.2017