Архитектура АВС
Проектирование высокодоступной базы данных с использованием Amazon Aurora
Понимание доступных вариантов проектирования для обеспечения высокой доступности с помощью Amazon Aurora.
В Amazon Aurora есть несколько вариантов, позволяющих реализовать высокодоступный и производительный уровень данных в вашем приложении. Однако из-за тонких различий в каждом параметре иногда может быть немного сложно найти, какие параметры подходят для вашего варианта использования.
В этой статье мы рассмотрим варианты и рассмотрим их различия, чтобы вы могли выбрать лучший вариант или использовать правильную комбинацию, которая наилучшим образом соответствует вашим требованиям.
Прежде чем мы рассмотрим варианты, давайте вернемся к тому, что такое кластер БД Aurora. Проще говоря, кластер Aurora — это один или несколько экземпляров базы данных, работающих как одна группа. Вы можете настроить кластер Aurora как с одним мастером или как с несколькими мастерами. Один мастер означает, что хотя все экземпляры в кластере могут обрабатывать операции чтения, только один экземпляр в кластере может обрабатывать операцию записи. Multi-master означает, что любой экземпляр в кластере может обрабатывать как операции чтения, так и записи.
Реплика Авроры
Реплики Aurora, также известные как экземпляры для чтения, представляют собой доступные только для чтения копии основного экземпляра в вашем кластере Aurora.
Реплики Aurora служат для двух основных целей:
- Масштабирование чтения: означает, что вы указываете на них приложения при выполнении операций чтения. Это не только уменьшит нагрузку на основной экземпляр, который обрабатывает записи, но и потому, что вы можете иметь до 15 реплик Aurora, которые можно распределить по зонам доступности, это означает, что вы можете еще больше распределить нагрузку для операций чтения.
- Цели аварийного переключения. Если экземпляр модуля записи в кластере становится недоступным, Aurora автоматически повышает уровень одной из реплик Aurora в качестве основной для обработки операций записи.
Репликация из основного экземпляра в экземпляры чтения происходит асинхронно и выполняется в течение миллисекунд. На момент написания AWS указывает, что задержка обычно намного меньше 100 миллисекунд, однако она зависит от скорости изменений базы данных. Репликация также оказывает незначительное влияние на первичный экземпляр, поскольку репликация выполняется на уровне хранилища/диска. Это также называется физической репликацией.
Одним из ключевых ограничений реплики Aurora является то, что она доступна только в том же регионе AWS, что и основной экземпляр. Вы не можете выйти за пределы этой области.
Логическая репликация
По сути, это реплики, созданные на логическом уровне базы данных с использованием функции репликации binlog MySQL или слотов репликации PostgreSQL. Они также могут выполнять требования к горизонтальному масштабированию для чтения и могут быть настроены в качестве цели аварийного переключения для достижения высокой доступности. Отличия от реплик Aurora заключаются в следующем:
- Можно настроить репликацию между регионами AWS, но Aurora изначально поддерживает это только для MySQL и только до 5 межрегиональных реплик для данного первичного кластера Aurora MySQL.
- Копировать дольше. Мы говорим о секундах, а не миллисекундах
- Аварийное переключение выполняется вручную
- Может использоваться для репликации другого кластера Aurora в том же регионе.
- Может использоваться в качестве реплики (подчиненной или подписчика) для совместимых баз данных в других местах, таких как RDS. Однако этот сценарий обычно используется для миграции с RDS на Aurora, а не для текущей репликации.
Следовательно, вероятно, самое большое преимущество использования собственной реплики чтения БД заключается в том, чтобы обойти ограничения реплики aurora или в тех случаях, когда у вас есть сценарии, в которых вам необходимо выполнить репликацию из RDS. Эти реплики можно настроить так, чтобы они находились в том же или другом регионе, что и первичная реплика. Таким образом, вы можете распределять свою базу данных и масштабировать чтение до 5 регионов за пределами основного региона, а также использовать их для регионального аварийного восстановления. Для дальнейшей оптимизации масштабирования чтения вы можете комбинировать это с репликами aurora. В каждом регионе может быть до 15 реплик Aurora. На приведенной выше диаграмме показан вторичный регион с 2 репликами.
Aurora Multi-Master
В кластере с несколькими мастерами все экземпляры базы данных в кластере имеют возможность чтения и записи.
Здесь понятия одного основного экземпляра для чтения/записи, отработки отказа в регионе и реплик Aurora не применяются. AWS называет это постоянной доступностью. По сути, Aurora с несколькими мастерами лучше всего подходит для горизонтального масштабирования записи в пределах региона и дополнительно повышает высокую доступность, предлагаемую кластером Aurora с одним мастером, но имеет несколько ограничений:
- В настоящее время поддерживается только MySQL
- Только до 4 экземпляров в кластере
- Доступно только в ограниченных регионах AWS. На момент написания статьи существует только 8 регионов, поддерживающих Aurora multi-master. Обязательно ознакомьтесь с официальной документацией AWS для получения последнего списка поддерживаемых регионов.
- Нельзя использовать с бессерверной версией Aurora.
- Нельзя использовать с глобальной базой данных Aurora.
Глобальная база данных Aurora
Глобальная база данных Aurora имеет 1 основной кластеррегион AWS и до 5 вторичных кластеров только для чтения в регионах AWS, отличных от основного. Запись выдается и обрабатывается только основным регионом. Проще говоря, это похоже на наличие реплик Aurora, но реплики находятся в другом регионе AWS.
Репликация по-прежнему асинхронна и быстра, поскольку использует физическую репликацию, но не так быстро, как реплика Aurora, которая находится в регионе, поскольку данные должны передаваться между регионами. В случае с глобальной базой данных Aurora мы обычно говорим о задержке репликации до секунды, что все же значительно быстрее, чем логическая репликация.
В глобальной базе данных Aurora каждый регион может иметь кластер, и один из этих кластеров обозначается как кластер. Сила этого заключается в том, что каждый кластер можно масштабировать независимо. При такой настройке вы можете иметь до 16 экземпляров реплики aurora в каждом дополнительном регионе.
Как и в случае с репликами Aurora, намерение использовать глобальную базу данных Aurora необходимо для масштабирования чтения, но в нескольких регионах AWS. Обычно это используется для обслуживания приложений с глобальным охватом. Он также может защитить вас от регионального сбоя, выполнив так называемый межрегиональный переход на другой ресурс, так как второй регион может быть повышен до основного в течение нескольких секунд. См. эту статью для получения дополнительной информации.
Одно из ограничений глобальной базы данных Aurora заключается в том, что до сих пор нет хорошего способа горизонтального масштабирования записи в разных регионах. Однако глобальная база данных Aurora имеет функцию переадресации записи. Хотя эта функция не улучшает производительность записи, она позволяет нам упростить приложение, поскольку приложениям не нужно будет поддерживать отдельные конечные точки записи и конечные точки чтения. Если приложение находится в дополнительном регионе, оно просто выполнит запись на конечную точку Aurora в том же регионе. Под капотом Aurora затем перенаправит этот запрос на запись в основной регион, который обрабатывает запись.
Здесь важно понять, что запись всегда происходит в основной области. При переадресации записи приложение не может ожидать, что данные будут обновлены до того, как они будут записаны в основной, а затем реплицированы обратно во вторичный, поэтому есть небольшая задержка, хотя и не большая.
Вот краткое дерево решений, которое поможет укрепить наше понимание и то, как ориентироваться в этих вариантах.
Во-первых, спросите себя, есть ли у вас потребность в масштабировании за пределы региона AWS. Если нет, то посмотрите реплику авроры или мультимастер. Если вам нужно масштабировать только операции чтения, выберите реплику aurora, если только вы не имеете дело со сценариями, включающими RDS или другую базу данных MySQL/PostgreSQL где-то еще. В противном случае используйте мультимастер.
Если вам нужно масштабироваться в регионах AWS, вы можете использовать глобальную базу данных Aurora, я думаю, что использование логической репликации будет довольно редким, если только ваш вариант использования Aurora не является достаточно конкретным, например, необходимо использовать его как реплика для RDS, миграция на Aurora или необходимость репликации только отдельных таблиц.
В заключение: как всегда, в этой статье представлены только базовые или отправные точки, но я надеюсь, что она поможет вам понять доступные варианты проектирования для обеспечения высокой доступности с помощью Amazon Aurora. Пожалуйста, прочитайте официальную документацию AWS и блоги, чтобы оценить и подтвердить свой вариант использования и подойти к нему более внимательно.
Спасибо за чтение.
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку здесь.
