Статическая стабильность с помощью зон доступности

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

Система, спроектированная с использованием статической стабильности, продолжает работать, даже если зависимость вышла из строя. Возможно, система не получает обновленную информацию, например новые, удаленные или измененные элементы, которую должна была предоставлять зависимость. Однако все другие операции, которые выполнялись до отказа зависимости, продолжаются. Мы опишем, как мы обеспечили статическую стабильность Amazon Elastic Compute Cloud (EC2). Затем мы предоставим два примера статически стабильных архитектур, которые кажутся нам полезными для создания высокодоступных региональных систем на основе зон доступности.

Наконец, мы подробно опишем некоторые принципы проектирования сервиса Amazon EC2, в том числе его архитектуру, которая обеспечивает независимость зоны доступности на уровне программного обеспечение. Кроме того, мы обсудит некоторые компромиссы, на которые приходится идти при создании сервиса с такой архитектурой.

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

В случае сбоя зоны доступности архитектура, показанная на предыдущей схеме, не требует никаких действий. Инстансы EC2 в отказавшей зоне доступности перестанут проходить проверки работоспособности, и Application Load Balancer перестанет направлять на них трафик. В действительности, сервис Elastic Load Balancing создан на основе этого принципа. Он выделяет достаточно ресурсов для балансировку нагрузки, чтобы справиться со сбоем зоны доступности без необходимости в вертикальном масштабировании.

Мы также используем этот шаблон даже при отсутствии балансировщика нагрузки или сервиса HTTPS. Например, группа инстансов EC2, которые обрабатывают сообщения из очереди Amazon Simple Queue Service (SQS), также могут использовать этот шаблон. Инстансы развертываются в группе Auto Scaling в нескольких зонах доступности с соответствующей избыточностью. При сбое зоны доступности сервис ничего не предпринимает. Затронутые сервисы перестают работать, а их нагрузку подхватывают другие.

Как и в примере конфигурации типа «активный-активный» без фиксации состояния, при сбое зоны доступности с основным узлом сервис с фиксацией состояния ничего не делает с инфраструктурой. Для сервисов, использующих Amazon RDS, сервис RDS управляет перебросом и меняет DNS-имя на новый основной узел в рабочей зоне доступности. Этот шаблон также применяется к другим конфигурациям типа «активный-резервный», даже если они не используют реляционную базу данных. В частности, мы применяем его в системах с архитектурой кластера, содержащей ведущий узел. Мы развертываем эти кластеры в зонах доступности и выбираем новый ведущий узел из резервных кандидатов, а не незамедлительно начинаем замену.

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

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

При развертывании мы используем принцип независимости зон доступности в Amazon EC2. В Amazon EC2 программное обеспечение развертывается на физических серверах, на которых размещаются инстансы EC2, периферийные устройства, преобразователи имен DNS, компоненты плоскости контроля в пути запуска инстанса EC2 и многие другие компоненты, от которых зависят инстансы EC2. Эти развертывания соблюдают зональный календарь развертывания. Это значит, что две зоны доступности в одном регионе получат данное развертывание в разные дни. В AWS мы используем поэтапное развертывание. Например, мы соблюдаем следующую рекомендацию, независимо от типа сервиса, в котором выполняется развертывание: сначала развертывается универсальный почтовый ящик, затем 1/N серверов и т. д. Однако для таких сервисов, как Amazon EC2, развертывания преднамеренно согласуются с границами зон доступности. Таким образом, проблема с развертыванием влияет на одну зону доступности, откатывается и устраняется. Она не влияет на другие зоны доступности, которые продолжают работу в нормальном режиме.

Другой способ применения принципа независимости зон доступности при разработке в Amazon EC2 заключается в том, чтобы все потоки пакетов оставались в зоне доступности и не пересекали ее границы. Второй пункт (сохранение сетевого трафика в зоне доступности) стоит обсудить подробнее. Это интересная иллюстрация того, что мы мыслим по-разному при создании региональной высокодоступной системы, которая является потребителем независимых зон доступности (то есть использует гарантии независимости зон доступности как основу для создания высокодоступного сервиса) и при предоставлении инфраструктуры независимых зон доступности другим, чтобы позволить им обеспечить высокую доступность.

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

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

Причины, по которым мы проектируем базовые сервисы независимыми от зон доступности, просты. Допустим, произошел сбой зоны доступности. Для простых сбоев Application Load Balancer автоматически осуществляет переброс затронутых узлов. Однако не все сбои такие очевидные. Могут существовать ошибки в программном обеспечении, которые балансировщик нагрузки не увидит во время проверки работоспособности и не сможет устранить.

В предыдущем примере, в котором один высокодоступный региональный сервис вызывает другой такой же сервис, если запрос отправляется через систему, то с небольшими упрощениями вероятность того, что запрос избежит затронутую зону доступности составляет 2/3 * 2/3 = 4/9. Это значит, что шансы запроса на сохранение устойчивости меньше одного к одному. И наоборот, если мы сделаем зеленый сервис зональным, как в текущем примере, то хосты в оранжевом сервисе смогут вызвать зеленый адрес в той же зоне доступности. С такой архитектурой вероятность избежать затронутой зоны доступности составляет 2/3. Если в этом пути вызова N сервисов, вероятность возрастает до (2/3)^N для N региональных сервисов и остается равной 2/3 для N зональных сервисов.

Поэтому мы создали шлюз NAT Amazon EC2 как зональный сервис. Шлюз NAT — это функция Amazon EC2, которая разрешает исходящий интернет-трафик из частной подсети и отображается не как региональный шлюз для всего облака VPC, а как зональный ресурс, который клиенты инициализируют отдельно в каждой зоне доступности, как показано на следующей схеме. Шлюз NAT размещается на этом пути интернет-подключения для VPC и поэтому является частью плоскости данных любого инстанса EC2 в этом VPC. Если произойдет сбой одной из зон доступности, мы хотим, чтобы он был изолирован в этой зоне, а не распространился и на другие зоны. В конце концов, мы хотим, чтобы клиент, который создал архитектуру, аналогичную описанной ранее в этой статье (инициализировал группы инстансов в трех зонах доступности с достаточными ресурсами в любых из двух зон для обработки полной нагрузки), знал, что другие зоны доступности никак не будут затронуты тем, что происходит в отказавшей зоне доступности. Единственный способ достичь этого – убедиться, что все базовые компоненты, например шлюз NAT, действительно остаются в пределах зоны доступности.

Это, в свою очередь, делает систему сложнее. Для нас в Amazon EC2 дополнительная сложность выражается в необходимости управления зональными, а не региональными средами сервисов. Для клиентов шлюза NAT она заключается в наличии нескольких шлюзов NAT и таблиц маршрутизации, которые используются в разных зонах доступности VPC. Эта сложность обоснована, так как шлюз NAT сам по себе является базовым сервисом, частью плоскости данных Amazon EC2, который должен предоставлять гарантии зональной доступности.

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

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

• Более простой шаблон: региональный сервис вызывает региональный сервис. Часто это лучший вариант для сервисов, доступных внешним пользователям, который также подходит для большинства внутренних сервисов. Например, при создании сервисов приложений более высокого уровня в AWS, таких как Amazon API Gateway и бессерверные технологии AWS, мы используем этот шаблон для обеспечения высокой доступности даже в случае сбоя зоны доступности.
• Более сложный шаблон: региональный сервис вызывает зональный сервис или зональный сервис вызывает зональный сервис. При проектировании внутренних, а иногда и внешних компонентов плоскости данных в Amazon EC2 (например, сетевых устройств или другой инфраструктуры, которая расположена напрямую на критическом пути данных) мы используем шаблон независимости зон доступности и инстансы, которые изолированы в зонах доступности, чтобы сетевой трафик оставался в одной зоне доступности. Этот шаблон не только гарантирует изоляцию ошибок в зоне доступности, но и позволяет сократить расходы на сетевой трафик в AWS.

В этой статье мы обсудили некоторые простые стратегии, которые мы использовали в AWS для успешного устранения зависимостей в зонах доступности. Мы поняли, что ключевой фактор для статической стабильности заключается в прогнозировании сбоев, прежде чем они произойдут. Если система работает в группе инстансов с горизонтальным масштабированием типа «активный-активный» или использует шаблон «активный-резервный» с фиксацией состояния, мы можем применять зоны доступности для обеспечения высоких показателей доступности. Мы развертываем системы так, чтобы все ресурсы, которые могут понадобиться в случае сбоя, уже были полностью выделены и доступны. Наконец, мы подробнее обсудили то, как сервис Amazon EC2 сам использует концепции статической стабильности для сохранения независимости зон доступности друг от друга.