Это глава из написанного мной «Руководства по сборке с помощью Serverless AWS». Для получения дополнительной информации о целях и фокусах руководства, пожалуйста, прочтите главу «Введение».

Оглавление:

  1. "Введение"
  2. Бессерверное введение
  3. Введение в облако и AWS
  4. Инфраструктура как код
  5. "Я"
  6. ВПК
  7. Лямбда
  8. API-шлюз
  9. ДинамоДБ
  10. S3
  11. Облачные часы
  12. Облачный фронт
  13. Маршрут 53 (Вы здесь)
  14. СНС
  15. СКС
  16. Кинезис
  17. Семейство инструментов разработчика
  18. Бессерверные контейнеры

Система доменных имен Amazon (DNS) называется Route 53. Route 53 легко интегрируется с другими сервисами AWS, обладает высокой доступностью, масштабируемостью и предлагает несколько интересных методов маршрутизации трафика. В прошлом я использовал Route 53, и мне это нравилось, но стоит отметить, что использование другого DNS (например, того, где куплено доменное имя) не лишает кого-либо возможности использовать пользовательские домены на AWS. Однако использование сервиса AWS вместо стороннего сервиса всегда имеет свои преимущества.

Последнее замечание, прежде чем я углублюсь в Route 53. Этот сервис на самом деле не является бессерверным в том смысле, в каком я его определил. Цены не обязательно указаны за запрос, но по самой природе DNS я не совсем уверен, что это возможно. При этом я не знаю ни одного другого DNS, предлагающего стиль ценообразования «за запрос». В любом случае, я считаю, что гибкость и простота интеграции Route 53 с другими сервисами AWS, которые я упомянул в этом руководстве, делают его достаточно полезным для включения.

Первым и самым большим преимуществом использования Route 53 является доступность. AWS предлагает 100% доступное соглашение об уровне обслуживания, что просто дико. Я никогда не слышал о другом сервисе в мире, который предлагает 100% доступность. Их стратегия предоставления чего-то столь нелепого не является секретом и опубликована в онлайн-документации, которую я предлагаю найти и прочитать, чтобы понять мощь этой системы, к которой мы можем подключиться. Опять же, AWS использует свое огромное глобальное присутствие, чтобы сделать сервис чрезвычайно доступным и масштабируемым.

Фундаментальной концепцией Route 53 является «хостинговая зона», которая представляет собой ту же идею, что и обычная зона DNS. Перед созданием DNS-записей необходимо создать размещенную зону в Route 53. Существует два типа размещенных зон: общедоступные и частные. Частные размещенные зоны используются для записей между VPC, поэтому я предполагаю, что вы не будете использовать их часто, если в вашей инфраструктуре не требуется такой тип сети. Общедоступные размещенные зоны — это то, что будет доступно в Интернете и сообщает пользователям, где найти ресурсы, которые они запрашивают.

Еще одна фундаментальная концепция Route 53 — проверка работоспособности. Это может звучать не так, как что-то, что относится к обычному DNS, и это правильно. Существуют сложные политики маршрутизации, предлагаемые через Route 53, которые основаны на проверках работоспособности для отработки отказа, и я буду обсуждать эти более сложные политики маршрутизации сразу после проверок работоспособности. Хотя эта концепция звучит так. Маршрут 53 проверяет, что цель, на которую он отправляет трафик, активна и готова к приему этого трафика.

Существует три типа проверок работоспособности: обычная проверка работоспособности, проверка работоспособности одного ресурса, комбинация проверок работоспособности различных ресурсов и проверка работоспособности на основе аварийного сигнала CloudWatch. Проверка работоспособности одного ресурса — это простая и стандартная проверка работоспособности, которая обращается к ресурсу, проверяет, отвечает ли ресурс, и показывает, запущен ли ресурс.

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

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

Наконец, я хотел рассказать о различных политиках маршрутизации, которые предоставляет нам Route 53. Типы маршрутизации на момент написания этой статьи: простая, отработка отказа, многозначный ответ, взвешенная, на основе геолокации, на основе задержки и на основе географической близости. Нам не обязательно придерживаться одной политики маршрутизации, поскольку AWS позволяет нам их комбинировать; однако лично я никогда не использовал комбинаторный подход и полагаю, что вариант использования будет довольно сложным. Две политики маршрутизации, которые я хочу обсудить, — это простая маршрутизация и маршрутизация на основе задержек. Это два, которые я использовал в проектах раньше и считаю наиболее полезными. Каждая политика маршрутизации имеет свои преимущества в зависимости от пользователей и варианта использования приложения, поэтому обо всех них стоит знать.

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

Маршрутизация на основе задержки добавляет немного аромата Route 53 в смесь стандартной DNS. Вместо сопоставления одного доменного имени с одним ресурсом мы можем использовать одно и то же доменное имя для нескольких ресурсов и динамически указывать пользователю ресурс, который обеспечит им наименьшую задержку. Для меня это замечательная функция Route 53, которая позволяет нам создавать динамические и распределенные приложения. Ситуация, в которой я использовал это, была глобально разнообразным приложением. Были региональные развертывания шлюзов API с интеграцией Lambda и глобальными таблицами DynamoDB, реплицируемыми в эти регионы. DNS обрабатывался политикой маршрутизации на основе задержки, которая перенаправляла пользователя к ближайшей к нему реплике приложения вместо использования разных доменных имен для каждого региона.

Я с большим успехом использовал Route 53 в качестве службы DNS для раздач API Gateway и CloudFront, на которых размещены веб-сайты. То, как AWS позволяет нам реплицировать ресурсы в разных регионах и направлять пользователей к ближайшему к ним набору, позволяет мгновенно уменьшить задержку. Все сервисы работают вместе и значительно упрощают и ускоряют создание распределенных приложений, что и является моей главной целью.

Следующая глава: SNSПредыдущая глава: CloudFrontКатегории: руководство по созданию бессерверных aws

Первоначально опубликовано на https://thomasstep.com 4 октября 2021 г.