Это глава из написанного мной «Руководства по сборке с помощью Serverless AWS». Для получения дополнительной информации о целях и фокусах руководства, пожалуйста, прочтите главу «Введение».
Оглавление:
- "Введение"
- Бессерверное введение
- Введение в облако и AWS
- Инфраструктура как код
- "Я"
- ВПК
- Лямбда
- API-шлюз
- ДинамоДБ
- S3
- Облачные часы
- Облачный фронт
- Маршрут 53 (Вы здесь)
- СНС
- СКС
- Кинезис
- Семейство инструментов разработчика
- Бессерверные контейнеры
Система доменных имен 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 г.