Перевод статьи: https://read.acloud.guru/the-quest-for-availability-771fa8a94a7c

На сколько баллов из 9 ваши клиенты счастливы?

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

Идея заключается в разделении серий по следующей структуре

1. Поиск доступности.
2. Создание многообластной, активной архитектуры.
3. Создание многообластного, активного бессерверного бэкэнда.
4. Взлом при помощи Chaos Engineering.

Конечно, структура может и вероятно изменится пока я продолжаю писать и получать ваши отзывы, поэтому не стесняйтесь управлять курсом этой истории ниже в комментариях ☺

Системная ошибка

Одним из моих любимых высказываний, повлиявших на мои мысли о разработке программного обеспечения, является высказывание от Вернера Фогельса, технического директора Amazon.com

“Сбои — это данность, и всё в конце концов со временем потерпит неудачу”

В действительности мы живем в хаотичном мире, в котором ошибка — первоклассный гражданин. Сбои обычно делятся на 3 разновидности; ранние сбои, изношенные (или поздние) сбои и случайные сбои — при этом каждый случается на разных этапах жизни любой системы.

Кривая интенсивности сбоев

Ранние сбои в основном связаны с ошибками программирования и конфигурации (опечатки, переменные мутации, сетевые проблемы, такие как порты и неправильная конфигурация маршрутизации IP, безопасность и т. д.). Со временем, когда продукт (или версия) становится зрелой, и вводится автоматизация, эти сбои, как правило, уменьшаются.

Примечание: Я только что упомянул «введение автоматизации! Это действительно означает, что вы должны использовать автоматизацию, чтобы прочувствовать это естественное снижение поведения ранних сбоев. Такая роскошь недоступна при работе вручную

«Изношенные» (или поздние) сбои — вы часто в Интернете читаете, что программные системы, в отличие от физических компонентов, не подвержены ошибкам износа. Собственно программное обеспечение работает на аппаратном обеспечении, не так ли? Даже в облаке программное обеспечение подвержено аппаратным сбоям и поэтому должно учитываться.

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

Случайные сбои в основном, именно случайны. Белка ест ваши кабели. Акула чистит зубы о трансатлантические кабеля. Пьяный водитель грузовика нацелен на центр вашей базы данных. Зевс играет с осветительными приборами. Не будьте дураком, в конце концов вы тоже станете жертвой смешных и неожиданных сбоев.

Скорость инноваций

Мы живем в среде, где скорость имеет решающее значение — и я имею в виду возможность постоянно поставлять программное обеспечение. Чтобы дать вам представление о скорости в масштабе, Amazon.com в 2014 году занимался примерно 50 миллионами внедрений в год, это почти 1.6 внедрений в секунду.

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

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

Как это действительно выглядит.

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

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

Чтобы помочь вам понять, с чем вы сражаетесь, я включил таблицу «Бесславных девяток» о доступности. Уделим минутку этой таблице.

«Бесславные девятки» доступности

Если вы хотите иметь 5-девятую доступность, вы можете позволить себе только 5 минут простоя в год!

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

Извлеченный урок: если кто-то из людей участвует в восстановлении вашей системы, вы можете сказать до свидания Бесславным Девяти.

Итак, как вы можете примирить как доступность, так и скорость для большего блага ваших клиентов? Существует три важные вещи, а именно:

1. Архитектура высоконадежных и доступных систем
2. Инструмент, автоматизация и непрерывная поставка
3. Культура

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

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

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

Понимание доступности

Представьте, у вас есть 2 компонента, X и Y с доступностью 99% и 99,99% соответственно. Если вы разместите эти два компонента последовательно, общая доступность системы ухудшится.

Последовательная доступность

Стоит отметить, что общая мудрость «цепь столь же сильна, как и слабое звено» здесь неверна — цепочка фактически ухудшается.

С другой стороны, если вы берете худшее из этих компонентов, в этом случае A имеет доступность 99%, но поставив его параллельно, вы резко увеличите общую доступность системы. Красота математики в работе, мои друзья!

Параллельная доступность

Что из этого нужно вынести? Компонентная избыточность значительно увеличивает доступность!

Примечание: Вы также можете рассчитать доступность со следующим уравнением:

Доступность вычислительной системы

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

Регионы AWS

На сайте AWS вы можете прочитать следующее:

Облачная инфраструктура AWS построена вокруг регионов и зон доступности («А-Я»). Регион — это физическое местоположение в мире, где у нас есть несколько зон доступности. Зоны доступности состоят из одного или нескольких дискретных центров базы данных, каждый из которых имеет избыточную мощность, сеть и возможности подключения, размещенные в отдельных помещениях.

Поскольку картина стоит 48 слов, регион AWS выглядит примерно так.

Пример региона AWS с 3 AZ.

Теперь вы, вероятно, понимаете, почему AWS всегда-всегда говорит и советует своим клиентам внедрять свои приложения через multi-AZ — желательно тремя из них. Просто из-за этого уравнения, мои друзья.

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

Приложение, внедренное через multi-AZ, используя эластичный балансировщик нагрузки (Elastic Load Balancer — ELB).

Это также является причиной того, что использование региональных сервисов AWS, таких как S3, DynamoDB, SQS, Kinesis, Lambda или ELB, просто для того, чтобы назвать некоторые из них, — хорошая идея — они по умолчанию используют несколько AZ под капотом. И именно поэтому использование внедрения RDS, настроенного в multi-AZ, является признаком аккуратности!

Цена доступности

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

Цена доступности

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

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

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

Принятие этого решения

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

Экспоненциальная отсрочка

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

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

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

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

В своей самой простой форме алгоритм псевдоэкспоненциального отклика выглядит так:

Простой алгоритм экспоненциального отклика

Примечание: Если вы используете одновременные клиенты, вы можете добавить джиттер к функции ожидания, чтобы ваши запросы выполнялись быстрее.

К счастью, многие SDK и программные библиотеки, включая AWS, внедряют версию (часто более утонченную) этих алгоритмов. Однако не полагайтесь на  предположение, всегда проверяйте и тестируйте его.

Очереди

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

Шаблон передачи сообщений с очередями.

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

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

Вишенка на торте

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