Решение построено с использованием глобальных таблиц DynamoDB, AWS Lambda, регионального API Gateway и политик маршрутизации Route53.

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

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

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

Обзор решения

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

Мы также будем использовать AWS Lambda для бизнес-логики и новой региональной конечной точки API в API Gateway. Наконец, наше решение использует политики маршрутизации Route53 для динамической маршрутизации трафика между двумя регионами AWS.

Приступим!

Шаг # 1: Создание глобальной таблицы в DynamoDB

Помните, что глобальная таблица DynamoDB состоит из нескольких таблиц-реплик, по одной на выбранный регион (в настоящее время поддерживается 5 регионов), которые DynamoDB рассматривает как единое целое. Каждая реплика имеет одно и то же имя таблицы и одинаковую схему первичного ключа.

Чтобы начать создание глобальной таблицы, откройте Консоль DynamoDB, создайте таблицу с первичным ключом. В нашем примере мы будем использовать MyGlobalTable с item_id в качестве первичного ключа и нажмите Создать . Эта таблица будет служить первой таблицей-репликой в ​​глобальной таблице.

  • После создания таблицы выберите вкладку Глобальные таблицы.
  • Вы заметите, что создать глобальную таблицу
  • Вы должны включить DynamoDB streams
  • Нажмите Включить потоки.

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

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

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

Вы можете сделать то же самое с AWS CLI - и на самом деле это приветствуется!

Затем вы можете протестировать глобальную таблицу следующим образом:

Вы заметили новые поля, созданные DynamoDB Global Table? В процессе межрегиональной репликации добавляются атрибуты aws: rep: updateregion и aws: rep: updatetime, поэтому вы можете отследить происхождение предмета; Оба поля могут использоваться вашим приложением, но, конечно, не должны изменяться.

Шаг № 2: Создание серверной части с использованием AWS Lambda и API Gateway

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

Региональные конечные точки шлюза API
Региональная конечная точка API - это новый тип конечной точки, доступ к которой осуществляется из того же региона AWS, в котором развернут ваш REST API. Это уменьшает задержку запроса, когда запросы API исходят из того же региона, что и ваш REST API.

Бэкэнд-функции
Для демонстрационных целей мы создадим три функции; один для публикации элемента в DynamoDB, второй для получения элемента из DynamoDB и проверка работоспособности, чтобы убедиться, что серверная часть работоспособна.

Примечание. Вы обратили внимание на чрезвычайную сложность функции здоровья? Я знаю ... это сделано для того, чтобы позже я мог легко протестировать механизм аварийного переключения в Route53. Будь умнее меня, пожалуйста :)

Для развертывания этих функций воспользуемся бессерверной структурой. Почему? Я использую его с тех пор, как он изначально был запущен как Челюсти, и мне он нравится - он такой простой. То же самое можно сделать и с моделью бессерверного приложения AWS SAM.

Шаблон для развертывания API с использованием бессерверной инфраструктуры следующий:

Примечание. Обязательно замените xxxxxxxxxxxxx в файле serverless.yml на свой идентификатор учетной записи AWS, в котором были созданы предыдущие таблицы DynamoDB.

Разверните API в Ирландии и Франкфурте - или в регионах, которые вы использовали для своих таблиц DynamoDB.

Примечание. Если при развертывании возникает ошибка, связанная с типом endpointType, закомментируйте ее в файле serverless.yml и выполните развертывание снова. Затем вы можете войти в консоль API Gateway и вручную преобразовать тип конечной точки в региональный.

Тестирование региональных API
Поскольку мы уже вставляли элемент «foobar» в базу данных ранее, мы можем попробовать получить к нему доступ через остальные API.

Большой! Наш товар доступен из обоих регионов. А теперь давайте создадим новый.

Замечательно - работает.

Шаг № 3: Создание собственных доменных имен

Затем давайте создадим конечную точку пользовательского доменного имени Amazon API Gateway для этих региональных конечных точек API. Для этого у вас должна быть размещенная зона и домен, доступные для использования в Route 53, а также сертификат SSL, который вы используете с вашим конкретным доменным именем.

Теперь запросите сертификат SSL в AWS Certificate Manager (ACM) в каждом регионе, где вы развернули серверную часть с API Gateway и AWS Lambda.

В конце этих шагов он попросит вас подтвердить ваш запрос либо по электронной почте, либо путем добавления специального набора записей в вашу конфигурацию DNS Route 53.

После того, как все будет проверено, вы можете настроить конечные точки шлюза API в каждом регионе, чтобы они имели собственное доменное имя. В обоих регионах вы фактически настраиваете одинаковое доменное имя. Обратите внимание, что сопоставление базового пути должно быть на корневом пути «/», а место назначения, ранее развернутый API, вместе с переменной stage - здесь dev.

Примечание. Убедитесь, что имя этого пользовательского доменного имени в поле имени совпадает с вашим доменным именем, иначе оно просто не будет работать (я использовал global.adhorn.me).

После того, как вы настроили новое имя личного домена, выберите Имя целевого домена - они понадобятся на последних этапах.

Шаг # 4: Добавление проверок работоспособности в Route 53

Если у вас есть два или более ресурсов, которые выполняют одну и ту же функцию, например, наш многорегиональный бэкэнд «активный-активный», вы можете использовать функцию проверки работоспособности Route 53 для маршрутизации трафика только к «работоспособным» ресурсам.

Давайте настроим нашу проверку работоспособности с помощью ранее развернутого API работоспособности.

Сделайте то же самое для API проверки работоспособности каждого региона. После завершения вы должны увидеть, как состояние работоспособности станет зеленым в проверках работоспособности на Route 53.

Шаг # 5: Добавление политики маршрутизации между регионами с помощью Route 53

Теперь последняя часть - добавление политики маршрутизации между двумя региональными API, развернутыми во Франкфурте и в Ирландии.

Войдите в консоль Route 53 и добавьте следующую политику трафика. Используйте имя целевого домена, созданное шлюзом API, при настройке имени личного домена, чтобы установить значение конечной точки в политике.

И, наконец, создайте DNS-имя записи политики с ранее созданной политикой трафика.

Вуаля! ваш мультирегиональный активный-активный бэкэнд готов к тестированию!

И это работает как шарм!

Шаг # 6: Тестирование функции переключения при отказе в Route 53

Измените значение, возвращаемое красивой (sarcasm…) функцией makehealthcheckcalls (), установив переменную среды STATUS в консоли AWS Lambda ( в eu-west-1, Ирландия) на номер 404 и сохраните.

Через некоторое время вы должны увидеть, что состояние проверки работоспособности на маршруте 53 меняется с "Работоспособно" на "Неработоспособно". В идеальном мире вы также должны создать будильник для проверки.

Теперь попробуйте создать несколько элементов в базе данных.

Как вы можете видеть ниже, все созданные новые элементы имеют регион eu-central-1 в качестве источника (Франкфурт), поэтому функция аварийного переключения с использованием проверки работоспособности в Route 53 сработали как положено.

Готово!

Теперь вам может быть интересно, так ли это - ну да. Этот пост представляет собой введение, чтобы дать вам новые идеи и, возможно, оспорить некоторые старые.

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

Причина, по которой я не включил аутентификацию, проста в том, что в настоящее время Cognito не поддерживает синхронизацию пользовательских пулов в нескольких регионах, поэтому нужно будет создать это вручную. На форуме уже есть ветка +1 для поддержки этой функции, поэтому, если вам тоже это нравится, добавьте свою ;-)

В этом посте мы рассмотрели создание бессерверной многорегиональной бэкэнда «активный-активный» на базе DynamoDB Global Tables, AWS Lambda и API Gateway. Мы также узнали, как маршрутизировать трафик между регионами с помощью Route 53, поддерживая при этом механизм аварийного переключения.

Я все еще поражен этим - поскольку всего несколько лет назад для этого потребовалось бы НАМНОГО больше работы. Еще в канун Рождества 2012 года стриминговый сервис Netflix пережил сбой, что в значительной степени стало отправной точкой их пути к построению активно-активной многорегиональной архитектуры. Именно тогда я влюбился в устойчивые архитектуры - и я надеюсь, что вы тоже вдохновитесь и раздвинете границы того, что возможно в настоящее время, чтобы разработать решения завтрашнего дня.

В следующей серии постов я расскажу о Chaos Engineering и особенно остановлюсь на том, почему следует практиковать взлом. И я буду использовать эту бессерверную многорегиональную архитектуру «активный-активный», представленную здесь, в качестве отправной точки для экспериментов. Будьте на связи!

[ОБНОВЛЕНИЕ] - здесь я опубликовал Поддержка VPC для AWS Lambda и DynamoDB!

  • "Адриан"